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1. GENERAL 


Reference 

Documentation 


1.01 Traffic measurements are essential for monitoring the performance 
of a switching machine, for identifying potential congestion problems 
and for planning future growth of the switching machine. The SL-1 
Business Communications Systems are equipped with traffic data 
accumulation capabilities which are resident in the system memory and 
function as part of the normal call processing software operations. 

1.02 The purpose of this practice is to describe the traffic measurement 
data a,cquired at an SL-1 switch, discuss the conditions under which the 
data is accumulated, interpret the traffic measurement data output 
formats and explain the command structures that are available to 
control the traffic data collection and printing. 

1.03 Overlay loading instructions are provided in the following practices 
(depending on machine type): 

553-2001-315 General Input/Output Information 

553-2YYl-311 Data Administration Manual II: Input/Output 

Reference Manual. 

1.04 For maintenance diagnostic information, refer to the following 
practices (depending on machine type): 

553-2001-505 \ Diagnostic Programs Description and 

Input/Output 

553-2301-511 Maintenance Manual II: Diagnostic Programs 

Description and Input/Output Reference 
Manual. 
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2. TRAFFIC MEASUREMENT OVERVIEW 


2.01 Switching in an SL-l system is accomplished via network loops 
and. for larger SL-1 systems, via network loops and network groups. (A 
network group consists of up to 16 or 32 network loops, depending on 
the system.) A network loop has 30 time slots that can be used to 
establish a network path (i.e., connection.) Time slots are grouped into 
matching pairs so that each time slot can be used with only one other 
time slot on the same or different network loop (except with Generic 
Xll Release 4 and later versions). A network path is a matched pair of 
time slots. 

Note: Generic Xll Release 4 and later versions do not have the 
time slot pairing constraint; i.e., any idle time slot on one network 
loop may be matched with any idle time slot on the other network 
loop to form a connection. 

2.02 A time slot is busy if it is in actual use or is reserved by the 
Central Processing Unit (CPU) for future use. Thus, a matching pair of 
time slots (i.e., network path) is idle only if both time slots are idle 
(except in Generic Xll Release 4 and later versions). 

2.03 There are three types of network path: 

(a) Intra-Loop. An intra-loop network path is a connection between a 
source and a destination that are on the same network loop. An 
intra-loop network path is idle only if there is an idle matching 
pair of time slots oii the same network loop (except in Generic Xll 
Release 4 and later versions). 

(b) Interloop (same network group). An interloop (same network 
group) network path is a connection between a source and a 
destination that are in different network loops, but are in the same 
network group. An interloop (same network group) network path is 
idle only if there is an idle matching pair of time slots, one time 
slot on each network loop (except in Generic Xll Release 4 and 
later versions). 

(c) Interloop (different network group). An in ter loop (different 
network group) network path is a connection between a source and 
a destination that are on different network loops within different 
network groups. An in ter loop (different network group) network 
path is idle if: 

• there is an idle matching pair of time slots, one time slot on 
each network loop (Generic Xll Release 4 and later versions 
allow the use of any idle time slot on either network loop) 

• the matching time slots are idle in at least one of the four 
junctors between the two network groups (eight junctors with 
Generic Xll Release 4 and later versions). 

DEFINITIONS 2.04 Terminal. A terminal is any set (500/2500-type or SL-1), trunk 

or attendant console. 

2.05 Connection Point. A connection point is any point to and from 
which a network path is possible. 
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PROCESS 


2.06 Peg Count. A peg count is a count of a particular event 

2.07 Failure to Match. A Failure To Match (FTM) occurs if no idle 
network path can be found between two given connection points. 

2.08 Usage. The usage of a resource (e.g., time slots of a loop, trunks 
of a given trunk group, junctors between network groups) is the time 
measurement, in 100 call~seconds (CCS), of how long the elements of 
the resource have been busy. 

2.09 Established Path. An established path between two terminals is a 
path in which the called terminal has answered and both terminals are 
in the talking connection. There are cases involving outgoing trunks in 
which the terminals are in a talking connection but, because the SL-1 
does not yet consider outpulsing to be complete, the path is not an 
established path. If this path is idled, then measurements requiring 
‘established connections’ will not be accumulated. 

2.10 Service Loop. A service loop is either a Tone and Digit Switch 
(TDS) loop or an MF Sender (MFS) loop. As both types of loops serve 
similar functions, they have similar traffic measurements. Whenever the 
term ‘service loop’ is used, it refers to either a TDS loop or an MFS 
loop. 

2.11 There are five facets to traffic data collection in SL-1: 
Accumulation. Holding, Printing. Control and Outputting. 

2.12 Accumulation. When the SL-1 system takes any action that has 
associated traffic measurement(s), the relevant peg counts, usages, etc., 
are updated in accumulating registers associated with those 
measurements. The traffic data are automatically accumulated by the 
call processing software regardless of any measurement schedules, 
options, thresholds, etc., that may or may not be in effect at the time. 

2.13 Whenever any network path is seized, the time of day, in units of 
2 s, is stored in a register associated with that network path. When the 
path is subsequently idled, the previously stored time is subtracted from 
the current time of day to give a ‘usage’ on the path. This usage is 
added to the appropriate accumulating register(s) according to what the 
network path was used for (e.g., dial tone, outgoing trunk connection, 
conference connection). All usages are collected in units of 2 s and 
converted to CCS at the time of printing. 

Note: Because the usage (in CCS) is rounded off to the nearest 
integer, usage of less than 50 call-seconds is printed as 0 CCS. 

2.14 Holding. According to user-defined schedules, the data in the 
accumulating registers are transferred into another set of registers, the 
holding registers. There is one holding register for each accumulating 
register. As a measurement is transferred from an accumulating register 
to the associated holding register, the accumulating register is set to 
zero so that it can start collecting data for the next period. The data in 
the holding registers can be examined and printed at will. Data in the 
holding registers do not change until the next scheduled transfer of data 
from the accumulating registers. 
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SOFTWARE 



2.15 Certain traffic measurements have an associated threshold. When 
measurement data is transferred into the holding registers, such 
measurements are compared with their thresholds and, if a measurement 
exceeds its threshold, then, regardless of the print options, a special 
message is printed together with one or more blocks of associated ^ta. 

2.16 Printing. When data is transferred from the accumulating registers 
to the holding registers, there are printing options that allow given 
blocks of data to be printed immediately. Furthermore, at any time 
before the next scheduled transfer of data, the holding registers can be 
accessed via the Traf fic Control Overlay Progr am and blocks of data 
can be printed at will. It is only possible to pnm data from the holding 
registers. The accumulating registers are not accessed other than to 
transfer data from them to the holding registers. 

Note: Depending on the amount and type of data requested to be 
printed, a fast printer (e.g., 1200 baud with no 300 baud machine 
sharing the same function) may be required for large systems. 

2.17 Control. The traffic measurement schedules, printing options, 
threshold levels and all other traffic-oriented parameters are controlled 
through the Traffic Control Overlay Program. This pro^am may be 
loaded into the overlay area of the system memory to print, adjust or 
redefine any of the control parameters. 

2.18 Outputting. The cycle of transferring data from the accumulating 
registers to the holding registers and the outputting of data is repeated 
in accordance with the user-defined traffic measurement schedules. 
When data is being output at the teletypewriter (TTY), the rate of 
printing is controlled by . the amount of time the CPU can allocate to 
the task. As a result, all data may be output at once or may be output at 
intervals over a short period. Outputting of data starts when the data 
has been transferred from the accumulating registers to the holding 
registers and is completed prior to the next data transfer from the 
accumulating registers. 

2.19 In addition to the traffic data accumulation programs in the call 
processing software, two traffic programs, a resident traffic print 
program and a trafhc control overlay program, are used by the SL-1 
system to print and control the call processing traffic measurements. 
(See the maintenance diagnostics reference manual for information 
about the relationship of these two programs to the other resident and 
overlay programs us^ by the SL-1 system to monitor and maintain call 
processing.) 

2.20 Permanently in system memory, the resident Traffic Print program 
performs the following functions automatically: 

• examines the traffic measurement schedules set up in the system 

• transfers traffic data from the accumulating registers to holding 
registers according to the defined schedules 

• prints the traffic data. 
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2.21 The Traffic Control overlay program resides on system tape and is 
designated overlay number 02. Before performing any tasks, this 
program must be loaded into the overlay area of the system memory. 
Loading can be done only from a teletypewriter (TTY). Once loaded the 
program enables the following functions to be performed: 

• query traffic schedules, traffic options, threshold levels, system 
identification (ID) and system time-of-day 

• modify the traffic schedules, traffic options and threshold levels 

• access traffic data in the holding registers 

• set the system time-of-day 

• change the system ID. 

2.22 When the required tasks are completed, the Traffic Control 
overlay program is aborted (by entering ****). With the traffic 
requirements defined to the system, control of the measurements is 
transferred to the resident traffic programs. 

2.23 The SL-1 system can be programmed to provide traffic 
measurement outputs: 

(a) for any defined day(s) of the week during a defined period of the 
year, specified by start day and end day 

(b) for any defined period of the day specified by the start and end 
hours; i.e., 

• hourly, on the hour 

• hourly, on the half-hour 

• half-hourly, on the hour and half-hour. 

2.24 The traffic measurement schedules are defined to control the 
period over which measurements are accumulated (hourly or 
half-hourly). After the proper interval, the resident Traffic Print 
program transfers the data from the accumulating registers to holding 
registers and resets the accumulating registers to zero so that 
measurements begin to accumulate for the next period. This transfer of 
data can occur hourly on the hour, hourly on the half-hour or every 
half-hour, as defined by the schedules. 

2.25 An SL-1 system reset (system reload) or system initialization 
cau^ traffic measuremente to be lost When a reset occurs it is 
indicated by SYSOOO being printed at the teletypewriter. An 
initialization is indicated by INIOOO being typed. 

2.26 System reset can be invoked manually or automatically by the 
system. It is invoked automatically in the event of a power failure or 
when system control dictates. On a system reset 

• data on the system tape is read into the system memory 

• calls cannot be originated while the reload is in progress 
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• traffic data in the accumulating and holding registers is lost 

• any changes to traffic schedules, traffic options or threshold levels 
made since last Equipment Data Dump must be redefined via the 
teletypewriter via the Traffic Control overlay program. 

2.27 Initialization can be invoiced automatically by the system or by 
manually operating the INITIALIZE button at the equipment. On a 
system initialize: 

• the system automatically rebuilds the transient data area required for 
call processing 

• call processing continues immediately following the initialization, 
which takes about 5 s 

• traffic data in the accumulating and holding registers is lost and the 
registers are set to zero. The traffic program then continues in the 
normal manner. 

WARNING MESSAGES 2.28 Whenever certain events occur during the accumulation of traffic 

data (e.g., initialization, system reload, change to the traffic schedule), a 
warning message is output preceding the traffic measurement data. 

2.29 TFS301. This message precedes traffic data that is output after an 
SL“1 initialization. The message warns that data has been corrupted by 
the initialization and should be ignored. 

2.30 TFS302. This message warns that the traffic schedule was changed 
during the interval covered by the traffic measurement data. 

2.31 TFS303. The associated traffic measurement data were 
accumulated over a period greater than one hour. 

Connections With High 2.32 When a network path is held for longer than one hour (36 CCS), 
Usage the accumulated usage can have a detrimental effect on hourly traffic 

studies. High-usage connections can result from: 

• data terminal connections 

• loop-start trunks that fail to provide suitable supervision 

• long talking connections 

• call processing faults 

• telephone set problems. 

2.33 To report connections with excessive CCS, two warning messages 
are provided: 

(a) TFS401. This message identifies connections that were held for at 
least 36 CCS but less than 50 CCS. The message includes the 
measurements (pegs and usage) in the regular traffic data. 

(b) TFS402. This message identifies connections that were held for 50 
CCS or longer. The message does not include the measurements 
(pegs and usage) in the regular traffic data. 
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2.34 Message output format is as follows: 

TFS40X CCS TNI TN2 TYPE 

where, 

• CCS gives the usage on the connection. 

• TNI and TN2 identify the terminals (Loop, Shelf, Card, Unit) 
involved in the connection. (Because the loops involved are 
identified, TFSOOl figures can be corrected for previous hours. Also, 
the information can be used to identify faulty hardware where this is 
the cause of the long holding time.) 

• TYPE is a number which identifies what use the network path was 
put to (see Table 2-A). 


Table 2-A 

NETWORK PATH USAGE IDENTIFICATION 


TYPE 

NUMBER 

USE 


0 

Dial Tone 


1 

Busy Tone 


2 

Overflow Tone 


3 

Ringback Tone 


4 

Tone Ringing 


5 

Miscellaneous Tone 


6 

Outpulsing 


7 

Unknown use of a TDS 


8 

Digitone Receiver 


9 

Incoming trunk speech path 


10 

Outgoing trunk speech path 


11 

Intracustomer speech path 


12 

Tandem trunk speech path 


13 

Reserved path not used 



2.35 The traffic TTY may not always be on-line to receive messages. 
There is, therefore, a requirement for some indication of connections 
with high holding times with the regular traffic data. Both TFS411 and 
TFS412 will be given with the regular traffic output if and only if 
either measurement is nonzero when at least one block of data (system 
or customer) is scheduled. 

(a) TFS411. This message provides a peg count of the number of 
connections that were held for at least 36 CCS but less than 50 
CCS, together with the total usage (CCS) on the connections. 

(b) TFS412. This message provides a peg count of the number of 
connections that were held for 50 CCS or longer, together with the 
total usage on the connections. 

2.36 If these figures indicate a potential problem, then the traffic TTY 
can be turned on for subsequent hours and the TFS 401/402 messages 
used to obtain more information. 
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2.37 Pegs, CCS, and timing measurements taken over a small number of 
calls (i.e., less than 5) should not be considered in isolation. The 
resolution of time measurements does not allow accurate timing for 
small samples. 

2.38 TFS501 and TFS502 are printed on the traffic TTY by the Audit 
program (overlay 44) if it encounters lost time slots on a loop or 
junctor, respectively. (A lost slot is one which has been incorrectly 
marked as busy by the system.) The Audit program releases all such lost 
time slots. These messages are intended as ‘information only’ for those 
analysing traffic statistics. As lost time slots are not allocated by the 
system to new connections, they present the problem of hi^er blocking 
probability on the affected loop or junctor. These warning messages 
should be taken into consideration when analysing the traffic statistics 
for the loops in question. 

2.39 TFS501 identifies the loop number and the number of time slots 
that were recovered. TFS502 identifies the junctor group number and 
the number of time slots that were recovered. 

2.40 When an SL-1 system is installed, a traffic measurement schedule 
is defined for the system and a possibly different schedule is defined 
for each customer sharing the system. Given the schedule, the traffic 
measurements involve the following: 

(a) The time-of-day. 

(b) A set of system traffic measurements which consists of: 

• peg count, usage and FTM of network 

• peg count, usage and FTM of services 

• dial tone delay 

• processor load 

• peg count, usage and FTM of lines 

• peg count, usage and FTM of junctors. 

(c) A set of customer measurements which consist of: 

• peg count, usage and FTM of incoming, outgoing, intracustomer 
and tandem calls, and peg count of unsuccessful attempts 

• trunk group peg count, usage and overflow count 

• attendant queue characteristics 

• attendant console traffic 

• route list usage 

• Network Class-of-Service (NCOS) 

• peg count of features. 

(d) Comparisons with the system threshold levels for: 
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• dial tone speed 

• loop traffic 

• junctor traffic. 

(e) Comparisons with the customer threshold levels for: 

• incoming matching loss 

• outgoing matching loss 

• average speed of answer 

• percent all trunks busy 

• Off-Hook Queuing (OHQ) overflow. 

2.41 The SL—1 system contains circuitry which generates timing signals 
that enable the CPU to execute real-time functions and keep an 
accurate time-of-day and date. To compensate for component 
tolerances, the time-of-day is corrected by making a daily adjustment. 
This adjustment is made automatically once a day at midnight. 

2.42 The time-of-day and date of the system can be queried and 
adjusted manually if required. The query and adjustment are made via 
the teletypewriter. The manual adjustment is also required in the event 
of a system reset 

2.43 The time-of-day and date is included as part of scheduled traffic 
data outputs. It immediately follows the TFSOOO header and precedes 
the traffic data. When the traffic data output is invoked via the Traffic 
Control program, then the time-of-day and date is not output The 
time-of-day and date can, however, be queried via the Traffic Control 
program. 

Note: In Generic Xll, the length of each field in the time and 
date is increased by one digit 

2-44 The time-of-day and date must be redefined after a system reset 
(system reload) occurs. 

WARNING: Since the traffic measurement schedule and 
midnight routines reference the time-of-day clock, these 
programs can be inadvertently triggered by time 
adjustment. For example, adjusting the time from 11:05 to 
10:55 will result in the output of traffic data when the 
system clock reads 11:00, provided It is scheduled. 

2.45 The system Identification (ID) is required when the SL-1 system is 
controlled from a central administration center. The system ID 
identifies the system from which the traffic measurements originate. 
Each SL-1 system is identified by a unique 3-digit number which is 
output as part of the traffic data. 
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2.46 The 3-digit system ID is assigned to the system when the traffic 
measurement schedules and options are defined. It is input the first 
time traffic schedules are defined. When traffic schedules or options 
are changed, the system ID number need not be redefined. It is 
redefined only when it is deemed necessary to change the system ID. A 
system ID can be queried if required. The system ID may also be 
changed using the configuration record program (overlay program 17). 
Any change to the ID is reflected throughout the system, irrespective of 
the overlay program used to make the change. 

2.47 Traffic data available for output are (schedules for each type of 
measurement can be defined independently): 

• System Measurements (accumulated on a system basis) 

• Customer Measurements (accumulated on a customer basis) 

• System Threshold Violations (tests on system measurements) 

• Customer Threshold Violations (tests on customer measurements). 

2.48 System measurements are identified by the prefix TFS. The 3-digit 
code following the prefix identifies the type of measurement: 


• TFSOOl 

• TFS002 

• TFS003 

• TFS004 

• TFS005 

• TFS007 


Networks (per loop) 
Services . 

Dial Tone Delay 
Processor Load 
Lines 

Junctor Group Traffic.. 


2.49 Customer measurements are identified by the prefix TFC. The 
3-digit code following the prefix identifies the type of measurement: 




TFCOOl ” Networks (per customer) 

TFC002 “ Trunks 
TFC003 “ Queue 
TFC004 ” Console 
TFC005 “ Features (Note) 

TFC006 - ARS and Ring Again (not applicable with Generic XU) 
TFC007 ~ System Park (Generic X07) 

TFC007 - Call Park (Generic Xll, X37) 

TFC008 - Integrated Messaging System (IMS) and Integrated Voice 
Messaging System (IVMS). 


Page 2-9 



PRACTICE 553-2001-450 


Customer Network 
Measurements 


Threshold Violation 
Measurements 


Line Traffic 
Measurement 


Note: Feature measurements can only be made on one customer at 
a time for a given system because only one holding area is 
provided. 

2.50 Customer network measurements (Generic XI1) are identified by 
the prefix TFN. The 3-digit code following the measurement identifies 
the type of measurement: 

• TFNOOl " Route Lists 

• TFN(X)2 ” Network Class-of-Service 

• TFN003 “ Incoming Trunk Group. 

2.51 System threshold levels can be defined for: 


(a) Dial Tone Speed. Failure to provide dial tone to a set within 3 s 
of the system recognizing the seizure of the line. Expressed as a 
percentage of total dial tone requests in units of 0.1%. 

(b) Loop Traffic. The network loop usage per hour. Expressed in 


(c) Junctor Traffic. The junctor group usage per hour. Expressed in 


2.52 Customer threshold levels can be defined for: 

(a) Incoming Matching Loss. Failure to match while attempting to 
set up a connection between an incoming trunk and an idle called 
line. Expressed as a percentage of total incoming connections in 
units of 0.1%. 

(b) Outgoing Matching Loss. Failure to match while attempting to 
set up a connection between a line and an idle outgoing trunk. 
Expressed as a percentage of total outgoing connections in units of 
0 . 1 %. 

(c) Average Speed of Answer. Average time, in units of 0.1 s, that 
calls wait to be answered by the attendant 

(d) Percent Last Trunk Busy. Last enabled trunk in a trunk group is 
made busy (incoming or outgoing). Expressed as a percentage of 
the total trunk connections in units of 0.1%. 

2.53 For each network loop a special set of lines and/or trunks can be 
defined. In addition to the normal traffic measurements, additional peg 
and usage measurements are made for this set of terminals. Lines 
and/or trunks to be included in this set are given the ITM (Individual 
Traffic Measurement) class-of-service (COS) and may be defined to the 
system via the Traffic Control program. (Attendants may not be given 
the ITM COS.) 
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3. SYSTEM TRAFFIC MEASUREMENT OUTPUTS 


3.01 Following are descriptions of the system measurements and their 
output formats. An example of an actual printout is included for each 
measurement. Peg count and thresholds are always given as a 5-<iigit 
number. Usage (accumulated CCS) and console measurements are given 
as 7-digit numbers. 

TFSOOO TRAFFIC PRINT 3.02 When the traffic data is first printed, TFSOOO is output before 
PROGRAM ENTRY either time-of-day or any other traffic data. 

TFS001 NETWORKS 3.03 Measurements of peg count, usage and Failure to Match (FTM) 

are made. Usage measurements are accumulated for each network path 
as it is idled, regardless of its use (or non-use). It gives the total time 
that time slots are marked as busy in the network maps and therefore 
unavailable for other use. Peg count and FTM measurements are never 
accumulated for maintenance functions (e.g., background signaling 
tests). 

3.04 One line of output is provided for each loop in the system. 
Although the format (Table 3-A) and measurements for each loop 
appear to be the same, the meanings of the measurements differ 
according to loop type. There are four types of network loops: 

• TERM(inal) " a loop containing lines, trunks, etc. 

• IDS “ a loop providing tones and DTMF or dial pulse outpulsing 

• MF(SENDER) “ a loop providing multifrequency outpulsing (AND 

• CONFERENCE " a conference loop. 

Note: TDS and MFS loops are termed service loops. 

Terminal Loops 3.05 Loop Peg Count. This measurement is incremented when an 

established path between two terminals is made idle. Idling the busy 
paths to tones, outpulses, etc., will not increase the TERMINAL loop 
peg count but accumulates the peg counts on the service loops. In a 
conference call, adding a new conferee terminal to the conference 
requires first establishing a path between the new conferee and the 
conference controller (the terminal initiating the conference). As the 
conference is established this direct path is idled, providing one peg for 
the conferee and one peg for the controller. When a conferee leaves a 
conference, a peg is made only on the conference loop. The overall 
effect is: 

(a) one peg per added conferee on its terminal loop 

(b) one peg per conferee, including the controller, on the conference 
loop 

(c) one peg per added conferee on the controller’s terminal loop; e.g., 
a 6-party conference will give 5 pegs under (a), 6 under (b) and 5 
under (c). 

Note: The pattern of FTMs accumulated can indicate which 
loop(s) cause the blocking. 
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Service Loops 


3.06 Loop Usage. The loop usage of a particular loop gives the total 
time that the time slots of the loop have been marked as busy and 
unavailable for other use. 

3.07 Loop FTM. The loop FTM is incremented when: 

(a) A terminal to terminal connection is blocked. In this case the loop 
FTM of both network loops is incremented. 

(b) A terminal or DTR to service loop path is blocked. An FTM will 

accumulate on both the service loop and the terminal loop. For any 
one call, at most one pair of FTM due to failure to find a tone 
path and/or one pair of FTM due to failure to find an outpulsine 
path can occur. r- © 

(c) A 2500~type set to DTR path is blocked. An FTM will accumulate 
on both the DTR loop and the terminal loop. For any one call, at 
most one pair of FTM per blocked idle DTR can occur. After the 
first pass at all DTRs, further attempts to find an idle DTR and a 
path to it (the system tries again automatically) will not accumulate 
further loop FTM. 

(d) A terminal loop to conference loop connection is blocked when 
either trying to form a new conference or to add a new conferee 
to an existing conference. 

3.08 I ntr a loop Peg Count. If a path is eligible for Loop Peg Count 
and both terminals are on the same network loop, then the Loop Peg 
count is incremented twice, once for each terminal, and the Intraloop 
Peg Count is incremented once. 

3.09 Intra-loop Usage. If the path is between two connection points 
on the same loop, then the usage for the call is added twice to Loop 
Usage (each connection point occupied one time slot and therefore two 
time slots were busy on the loop) and once to the Intraloop Usage. 

3.10 Intraloop FTM. When a path is eligible to accumulate Loop FTM 
and both terminals are on the same loop, then loop FTM is incremented 
twice (once for each terminal) and Intraloop FTM once. 

3.11 Loop Peg Count. The count is incremented whenever a path to the 
loop is made idle. 

3J2 Loop Usage. Loop usage gives the total time that time slots of 
this loop have been marked busy and unavailable for other use. 

3.13 Loop FTM. When a path (for either a tone or outpulsing) is 
required between a terminal loop and service loop then, in general 
(maintenance routines are one exception), all service loops (of the 
appropriate type) in the system will be looked at to see if a path is 
available. If no path can be found to any service loop, then Loop FTM 
is incremented on the LAST service loop looked at. If a path is found, 
then no Loop FTM is accumulated for any loop. Within a given 
network group, service loops are looked at in a fixed order. Normally, 
one service loop, the first choice, accumulates most of the peg and 
usage traffic, whilst another service loop, the last choice, accumulates 
all of the Loop FTM measurements. When repeated attempts are made 
by the system to find a path to provide a service (e.g., dial tone) then 
any attempt after the first does not accumulate further Loop FTM. 
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3.14 Intraloop Peg Count, Usage and FTM. These measurements have 
no meaning for service loops and should always be zero. 

Conference Loops 3.15 Loop Peg Count. This is incremented once when an established 

path between a connection point and the conference loop is idled. The 
connection point’s loop peg count is not incremented. Each conferee of 
a conference requires one path between that terminal and the 
conference loop. This measurement, therefore, gives the total number of 
conferees that were involved with the given conference loop. 

3.16 Loop Usage. This measurement gives the total time that time slots 
of this loop have been marked as busy and unavailable for other use. 

3.17 Loop FTM. The conference loop FTM is incremented in two 
circumstances: 

(a) No conference loop can be found to establish a new conference. In 
this circumstance, all conference loops of the system will have been 
looked at and the measurement will accumulate against the last 
conference loop to be looked at. The order in which conference 
loops are used is not fixed and, therefore, the last one to be looked 
at is not always the same one. 

(b) A new conferee cannot be added to an existing conference. 

3.18 Intraloop Peg Count, Usage and FTM. These measurements are 
meaningless for confer^ce loops and should always be zero. 

* 3.19 Each individual failure to match indicates that no idle path could 

be found between the two loops but does not reflect the busy/idle 
status of the loop(s). The pattern of FTM accumulated can indicate 
which loop(s) cause the blocking. When a path to a service loop is 
required, each service loop in the system is searched to find the path. If 
a path to a service loop cannot be found, the FTM is pegged on the 
terminal loop of the LAST service loop tested. Example: 

(a) A single SL-1 set to SL-1 set interloop call pegs once on each of 
the terminal loops, 

(b) A 3-party conference pegs once on each terminal loop involved 
and three times on the conference loop. 

Note: In both examples the tones involved peg once per tone on 
the relevant lone and digit loop but not on the terminal loops. 
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Table 3-A 

TFS001 NETWORKS - FORMAT AND EXAMPLE 



FORMAT: 








System ID 

TFSOOl 







Loop 

Loop 

Intra 

Intra 

Intra 

Loop 

Loop 

Loop 

Number 

Type 

FTM 

CCS 

PC 

FTM 

CCS 

PC 

EXAMPLE: 








300 TFSOOl 







00 

TERM 

00000 

0000006 

00004 

00000 

0000064 

00056 

01 

TERM 

00000 

0000035 

00022 

00000 

0000123 

00086 

02 

TERM 

00000 

0000031 

00020 

00000 

0000126 

00075 

05 

CONF 

00000 

0000000 

00000 

00000 

0000000 

00000 

07 

TDS 

00000 

0000000 

00000 

00000 

0000000 

00000 

08 

TERM 

00000 

0000019 

00011 

00000 

0000143 

00098 

09 

TERM 

00001 

0000089 

00066 

00002 

0000194 

00149 

13 

TERM 

00000 

0000000 

00000 

00000 

0000025 

00006 

15 

TDS 

00000 

0000000 

00000 

00000 

0000031 

01496 

Note: 

In Generic XU, the 

loop number is expressed as a 

3-digit number. 




TFS002 SERVICES 


3.20 TFS002 gives three categories of service measurements. The 

meaning of the measurements differs according to the type of service. 

The following measurements are provided for all services except 

Digitone receivers and Conference loops: 

(a) Service Request Peg Count. This measurement is incremented 
whenever a path between a terminal and a service loop is idled. 
The service provided (tone, outpulser or mf tones) defines which 
service request peg count to be incremented. An outpulser is held 
busy for the duration of outpulsing. This measurement, therefore, 
increments once per outgoing (or tandem) call that at least starts to 
outpulse digits. If it cannot be determined which service was being 
provided by a TDS loop then miscellaneous tone is assumed and the 
miscellaneous tone service peg count is incremented. 

(b) Service Usage. This gives the time that the path to the service 
loop was busy. This is not necessarily the same time as the time 
during which the service was actually applied, as certain paths (e.g., 
outpulsing) are reserved before they are to be used and only idled 
when it is certain that they are no longer required. 

(c) Service FTM. When no path can be found between a terminal and 
any service loop then the appropriate Service FTM, according to 
the path’s purpose, is incremented. When repeated attempts are 
made by the system to obtain a path for a service (i.e., dial tone, 
overflow tone or outpulser) then any attempts after the first will 
not accumulate further Service FTMs. 
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Conference Service 


Digitone Service 


SL-1 Tone Detector 
(SL1TD) Service 


3.21 The conference service measurements are obtained by adding 
together all the TFSOOl Network measurements for all conference loops 
in the system. Conference measurements are on a per conferee basis, 
e.g., a 3-party conference held for 200 s pegs three times with usage 
equal to 6 CCS. 

3.22 Service Request Peg Count. This count is incremented when a 
path between a Digitone receiver and a terminal is idled. It gives the 
number of times that Digitone receivers are used. 

3.23 Service Usage. This gives the time that the path between the 
Digitone receiver and the originating party was busy. It is accumulated 
when that path is made idle. 

3.24 Service FTM. This count is incremented when at least one idle 
Digitone receiver exists in the system but the system cannot find a path 
between the originating party and any of those DTRs. It is not 
incremented in the case where some idle DTRs cannot be used due to 
network blocking and a subsequent idle DTR is successfully used for the 
call. In the case where the system cannot provide dial tone through a 
DTR but the path between the originating party and the DTR is 
available, one dial tone FTM is accumulated under TFS002. DTR FTM 
does not peg unless no path can be found between the originating party 
and any idle DTR. When the system makes repeated attempts to find a 
path to an idle receiver, any attempts after the first do not accumulate 
further Service FTM. 

3.25 Service Request Peg Count. This peg is incremented when the 
path between the SLITD and the trunk is idled. It gives the total 
number of times that tone detectors are used. 

3.26 Service Usage. The service usage peg is accumulated when the 
path between the tone detector and trunk is idled and gives the amount 
of time that the path was busy. 

3.27 Service Failure To Match (FTM). This peg is incremented when 
no path is available between an idle tone detector and a trunk. 

3.28 One line of output is provided for each type of service in the 
system (Table 3-B). ^ch type of service is identified by a number 
(expressed as 3-digits in Generic XU): 

00 for Dial Tone 

01 for Busy Tone 

02 for Overflow Tone 

03 for Ringback Tone 

04 for Tone Ringing SL-1 Sets 

05 for Miscellaneous Tone 

06 for Outpulsers 

07 is Spare 

08 for Digitone Receiver 
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09 for Conference 

10 for MF tone for ANI 

11 for SL-1 Tone Detector. 

3.29 Dial tone, busy tone, overflow tone, ringback tone, tone ring and 
Digitone receiver all peg once per connection to the service. Outpulsers 
peg once each time they are used in a normal outgoing call. 
Miscellaneous tone includes override, busy verification, etc. When an 
attempt to find a network path between a terminal and a service loop 
results in a failure to match: 

(a) Requests for Digitone receivers, dial tone, overflow tone and 
outpulsers connections are placed in queues and periodic attempts 
to find a network path are made. 

(b) Requests for tones other than dial tone and overflow tone are 
abandoned. 

(c) Conference connections are replaced by overflow tone. The console 
tone and the SL-1 buzzing tone are not provided by the tone and 
digit switch. 
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Table 3-B 

TFS002 SERVICES " FORMAT AND EXAMPLE 


FORMAT: 


System ID TFS002 

Service Request 

Number FTM 

EXAMPLE: 


Service Request 

Usage PC 


200 TFS002 


00 

00000 

0000005 

00317 

01 

00000 

0000001 

00027 

02 

00000 

0000001 

00004 

03 

00000 

0000013 

00154 

04 

00000 

0000007 

00091 

05 

00000 

0000000 

00000 

06 

00000 

0000004 

00898 

07 

00000 

0000001 

00005 

08 

00000 

0000000 

00000 

09 

00000 

0000025 

00006 


Note: In Generic Xll, the service number is expressed as a 3-digit 
number. 


TFS003 DIAL TONE 3.30 TFS003 measurements (Table 3-C) give details of delays between 

DELAY the time the system recognizes a request for dial tone and the time 

when either that tone is provided or the requesting terminal abandons. 

(a) Dial Tone Delay for greater than 3 s. This is a count of the 
number of calls for which dial tone was delayed for greater than 3 
s, 

(b) Dial Tone Delay for greater than 10 s. This is a count of the 
number of calls for which dial tone was delayed for greater than 
10 s. A call that is delayed for greater than 10 s will increment 
both this count and the greater than 3 s count. 

(c) Total of All Delays Not Less Than 1 s. This measurement, in 
units of 1 s, gives the total delay suffered by requests for dial tone 
for all requests that were delayed for at least 1 s. 

Note: These peg counts include both successful and aborted 
connections. Mays longer than 10 s increment both pegs. 
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Table 3-C 

TFS003 DIAL TONE DELAY “ FORMAT AND EXAMPLE 


FORMAT: 



System ID 

TFS003 


Delay 
>3 s 

Delav 

>10's 

Total Delays 
> or = 1 s 

EXAMPLE: 



200 TFS003 



00003 

00001 

0040 


TFS004 PROCESSOR 
LOAD 


3.31 The Processor Load output (Table 3-D) gives peg counts for idle 
cycle count, total CPU attempts, load peak peg, input/output buffer 
overflow and call register overflow. 


3.32 Idle Cycle Count. The idle cycle count gives an indication of the 
load on the CPU. As the load increases, the idle cycle count decreases 
and vice-versa. This count is incremented every time the processor does 
not have any of the following tasks to perform: 

• Input messages (including timing marks) 

• 128 ms timing tasks (high-priority or low-priority) 

• Ring/queue activity 

• TTY input 

3.33 Total CPU Call Attempts. This is incremented once for each of: 

• Dial tone request 

• Incoming trunk seizure 

• Attendant origination to initiate a call 

• Each attempt the attendant makes to e.xtend a call. 

3.34 Load Peak Peg. This is a count of the number of times that, 
vvithin a 128 ms period, the processor does not have time to complete 
all the necessary 128 ms timing tasks (or tasks of a higher priority than 
the 128 ms timing). 
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3.35 I/O Buffer Overloads. These are counts of the number of times 
that incoming or outgoing signaling messages have been lost due to 
buffer overflow. The buffers involved are the high-priority input 
buffers (HPIB) and low-priority input buffers (LPIB) and the output 
buffers (OB) “ one for output to SL-1 sets and one for output to other 
than SL-1 sets (e.g., 500/2500 sets, trunks, etc.). If any I/O buffer 
overflow peg is non-zero, it indicates either an extreme traffic load, a 
hardware fault or that the given buffer is under-engineered. (Refer to 
553-2YY1-151 for recommended buffer sizes.) 

3.36 Call Register (CR) Overflow. This is a count of the number of 
times call processing software failed to find an idle call register. Each 
peg represents either a lost CDR ((2all Detail Recording) record, a lost 
call or an incompleted feature. When a call register is required for 
either a call or a feature and none are free, but there are CDR records 
awaiting processing, then a call register is removed from the CDR 
queue and used for the call or feature. In this way calls and features are 
completed at a possible expense of CDR records. (Refer to 
553-2YY1-151 for call register provisioning guidelines.) 

Real Time Load 3.37 To determine the real time load, two measurements are required: 

an ‘idle’ idle cycle count and a ‘busy’ idle cycle count. 

(a) The ‘idle’ idle cycle count should be measured over a 1 h period 
when the switch is, ideally, not processing any calls (Note). Too, 
the background overlay program, as defined in the configuration 
record, should be removed from the configuration record for the 
duration of the measurement period and all TTY ports should be in 
a logged out state. 

Note: A few calls can be tolerated to provide a fairly accurate 
‘idle’ idle cycle count, however, the number of calls processed 
should not exceed 3 % of calls processed during a busy hour. 

(b) The ‘busy’ idle cycle count should be measured over the ‘busy hour’ 
of the day (i.e., normal call processing operation, background 
overlay program running) in the average busy season. Typically, 
this measurement should be accumulated over a traffic study 
period of two weeks, the results averaged, and the resultant figure 
used as the ‘busy’ idle cycle count. 

3.38 The percentage of real time used (%RTU) can be determined with 
the following formula: 

%RTU = [(IICC — BICO/IICCl X 100 

where 

IICC = ‘idle’ idle cycle count 
BICC = ‘busy’ idle cycle count 

\ 3.39 To calculate the percentage of real time remaining (% RTR), use 

the following formula: 

% RTR = [ (BICC/IICC) - (1 + 2500/3600) 1 X 100. 
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Table 3-D 

TFS004 PROCESSOR LOAD - 


Note: The factor 2500 is derived by derating the number of 
seconds in one hour (3600) such that there is 91% real time 

Average Busy Season Busy Hour 
fo provide the High Day Grade of Service (i.e 
im of calls experience dial tone delay greater than 3 s). 


FORMAT AND EXAMPLE 


FORMAT: 

System ID TFS004 


(Idle Cycle Count) (CPU Attempts) (Lxjad Peak Peg) 
(HPIB Overflow Peg) (LPIB Overflow Peg) 

(500/2500 OB Overflow Peg) (SL-1 OB Overflow Peg) 
(CR Overflow Peg) 


EXAMPLE: 

200 TFS004 

1474233 00446 00001 

00000 00000 

00000 00000 

00000 


TFS005 LINES 


3.40 These measurements (Table 3-E) are associated with a given set of 
terminals (not including attendants) on each loop. These are the 
terminals that are assigned the ITM COS. Usage and peg count 
mea^rements are accumulated for any one group of lines and/or 
trunks per terminal loop. The measurements include all the counts that 
are pegged in TFCOOl. 


Count. For terminals other than trunks. When an 
established path involving a . terminal with ITM COS is idled, then Line 
Peg Count is incremented for the terminal’s loop. If both terminals of 
an established path have ITM COS then two Line Peg Counts will 
accrue, one for each terminal. In addition, when an established path 

^ conference is idled then, if that terminal has 
ITM COS, Line Peg Count is incremented for the terminal’s loop. 

2*^2 For all trunk terminals the Line Peg (Tount is incremented when 
the trunk with ITM COS is idled if, at any time since the trunk was 
seized, it was involved in an established connection. 


3.43 Line Usage. This is the total usage for all calls contributing to 
Line Peg Count • 
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Table 3-E 

TFS005 LINES “ FORMAT AND EXAMPLE 


FORMAT: 

System ID 

TFS005 


Loop 

Line 

Line 

Number 

Usage 

PC 

EXAMPLE: 

200 TFS005 


00 

0000034 

00045 

01 

0000012 

00009 

02 

0000054 

00012 

08 

0000121 

00101 

09 

0000021 

00019 

13 

0000000 

00000 


TFS007 JUNCTOR 
GROUP TRAFFIC 




3.44 A Junctor Group consists of four unidirectional junctors (eight in 
Generic XI1 Release 4 and later versions) between one network group 
and another. The Junctor Group going from network group X to 
network group Y is specified by the number XY. The numbering of the 
network groups and their respective loops are: 

• network group 0 contains loops 0 to 15 (0 to 31 in Generic XU 
Release 4 and later versions) 

• network group 1 contains loops 16 to 31 (32 to 63 in Generic XU 
Release 4 and later versions) 

• network group 2 contains loops 32 to 47 (64 to 95 in Generic XU 
Release 4 and later versions) 

• network group 3 contains loops 48 to 63 (96 to 127 in Generic XU 
Release 4 and later versions) 

• network group 4 contains loops 64 to 79 (128 to 159 in Generic XU 
Release 4 and later versions). 

Example: Junctor 02 is the junctor between network group 0 (loops 0 to 
15 or 0 to 31) and network group 2 (loops 32 to 47 or 64 to 95). 

3.45 The measurements under TFS007 (Table 3-F) all refer to paths 
between two connection points that are on different network groups 
and therefore involve the intergroup junctors. Three items are 
measured: the junctor peg count, the junctor usage and the junctor 
Failure To Match (FTM). 
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3.46 Junctor Peg Count. The Junctor Peg Count is the total count for 
completed c^ls between network groups where a talking path has been 
established. Connections from tone and digit loops do not affect the 
peg count The Junctor Peg Count is incremented whenever the path 
satisfies the conditions specified under TFSOOl, Loop Peg Count 

3.47 Junctor Usage. When any path between two connection points on 
different network groups is idled, the usage of that path is accumulated 
m Junctor Usage. This measurement therefore, gives the total time that 
time slots of the junctor group were busy and unavailable for other use. 

3.48 Junctor FTM. The Junctor FTM is the count of a failure to 
match while attempting to set up a connection between network groups. 
The Junctor FTM is incremented whenever a path is blocked and the 
conditions under TFSOOl, Loop FTM, are satisfied. 

3.49 One line of output containing the junctor number, junctor failure 
to match, junctor usage and junctor peg count is given for each junctor 
group. 


Table 3-F 

TFS007 JUNCTORS - FORMAT AND EXAMPLE 


FORMAT: 


System ID TFS007 


Junctor 

Group 

EXAMPLE: 

222 TFS007 


Junctor 

FTM 


Junctor 

Usage 


Junctor 

PC 


00001 

00000 

00002 


0002344 

0002122 

0001993 


01667 

01322 

00922 
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3 .00 SCOPE OF HEASDREflENTS 


3-01 When an SL-1 system is installed, a traffic measurenent schedule 
is defined for the systen and a possibly different schedule is defined 
for each customer sharing the system. Given the schedule, the traffic 
measurements involve the following: 

a) time-of-day. 

b) a set of system traffic measurements consisting of 

dC^ 

1) peg count, usage and FTH of networJc, 

2) peg count, usage and FTM of services, 

3) dial tone delay, 

4) processor load, 

5) peg count, usage and FTH of lines 

6) peg count, usage and FTH of junctors 

c) a set of per customer measurements consisting of 

1) peg count, usage and FTH of incoming, outgoing, intra¬ 
customer and tandem calls, and peg count of ineffective 
attempts, 

2) trunx group peg count, usage and overflow count, 

3) attendant queue characteristics, 

4) attendant console traffic, 

5) peg count of features 

d) comparisons with tne system threshold levels of 

1) Dial tone speed, 

2) Loop traffic, 

3) Junctor Traffic 

e) comparisons with the customer threshold levels of 

1) Incoming matching loss, 

2) Outgoing matching loss, 

3) Average speed of answer, 

4) Percent all trunks busy. 

3.02 The request for this information must be put into the system by 
the operating company, using the procedures outlined in this 
section .Detailed descriptions of the measurements are given in Parts 4 
to 9. 
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4. CUSTOMER TRAFFIC MEASUREMENT OUTPUTS 


4.01 Following are the descriptions of the customer measurements and 
their output formats. An example of the actual printout of each 
measurement is given. 

TFC001 NETWORKS 4.02 The measurements under TFCOOl give the peg count, usage and 

FTM of incoming, outgoing, intra-customer and tandem calls. Counts 
of ineffective attempts are also included. The output is printed on a 
customer basis (Table 4-A). 

Incoming Calls 4.03 Incoming Peg Count. Incremented when a trunk is idled if: 

(a) when originally seized it w'as incoming, and 

(b) at some time since it was seized it was involved in an established 
connection. 

4.04 Incoming Usage. When an established path between any terminal 
and a trunk is idled and if the trunk was originally incoming, the 
Incoming Usage is accumulated. 

4.05 Incoming Failure to Match. If, at any time between an incoming 
call being recognised by the system and the time that the trunk is idled 
the call suffers blocking so that a given stage of the call cannot be 
completed, then Incoming FTM is incremented. Any one call, at most, 
increments Incoming FTM once. 

4.06 Example. If a call cannot be presented to an idle attendant due to 
blocking, then an Incoming FTM is incremented. If the call is 
successfully presented to an attendant, but the attendant cannot extend 
the call to an idle terminal due to blocking, then an Incoming FTM is 
incremented. Even though a call may suffer both these types of 
blocking Incoming FTM is incremented only once. 

Outgoing Calls 4.07 Outgoing Peg Count. Incremented when a trunk is idled if: 

(a) when originally seized it was outgoing, and 

(b) at some time since it was seized it was involved in an established 
connection with another terminal. 

4.08 Outgoing Usage. When an established path is idled and one of 
the terminals is a trunk, then, if that trunk was outgoing when 
originally seized, the outgoing usage is accumulated. 

4.09 Outgoing FTM. If a path to an idle outgoing trunk cannot be 
found due to network blocking then the outgoing FTM is incremented. 
Any one call can only increment the outgoing FTM once. Further 
attempts to secure a trunk via, for example. Ring Again will not cause 
further outgoing FTM. 

intracustomer Calls 4.10 Intracustomer Peg Count. Incremented when an established path 

between two terminals, neither of which is a trunk, is idled. 

4.11 Intracustomer Usage. The total usage of all calls that increment 
Intracustomer Peg Count. 
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Tandem Calls 


Ineffective Attempts 


4.12 Intracustomer FTM. Incremented when a path cannot be found 
between two terminals, neither of which is a trunk. 

4.13 Tandem Peg Count. Incremented when an established connection 
between two terminals, both of which are trunks, is idled and both 
trunks are also to be idled. A tandem call does not increment either 
Incoming or Outgoing Peg Counts. 

4.14 Tandem Usage. When an established path between two terminals, 
both of wnich are trunks, is idled then tandem usage is accumulat ed . 

4.15 Tandem FTM. When a path between two terminals, both of which 

^ found due to network blocking, then Tandem 
FTM IS incremented. Two attempts are made to find a path between the 
oripnating trunk and an idle outgoing trunk. If both attempts fail, one 
tandem FTM is pegged. 

4.16 Partial Dial. Incremented for 2500-type sets only when dialing is 

not completed within 30 s. ® 

4.17 Abandon. Incremented when a terminal, other than a trunk, goes 
on hook and thus abandons a call before having dialed a complete 
directory number or a trunk access code. This count will not increment 
if a partial number has been outpulsed on a trunk route. 

4.18 Permanent Signal. Incremented when: 

• a terminal does not start dialing within 30 s of receiving dial tone 

• a terminal, other than a trunk or attendant, does not continue dialing 
once it has started and is placed into the line-lockout condition. 
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Table 4-A 

TFCOOl NETWORKS - FORMAT AND EXAMPLE 


FORMAT: 

System ID TFCOOl 



Customer Number 

Incoming FTM 

Incoming CCS 

Incoming PC 

Outgoing FTM 

Outgoing CCS 

Outgoing PC 

Intra-Customer FTM 

Intra-CXistomer CCS 

Intra-Customer ' 

Tandem FTM 

Tandem CCS 

Tandem PC 

Permanent Signal 

EXAMPLE: 

200 TFCOOl 

Abandon 

Partial Dial 

00 

00000 

0000092 

00072 

00000 

0000114 

00074 

00000 

0000063 

00083 

00000 

0000005 

00003 

00001 

00016 

00000 


Note: In Generic XU, the customer number is expressed as a 3-digit number. 


TFC002 TRUNKS 4.19 An output (Table 4-B) is given for each trunk group of each 

customer. The data includes peg count, usage, overflow, all trunks busy 
and toll peg count The trunk type may be: 

• Watts lines (WATT) 

• Foreign Exchange (FEX) 

• Common Control Switch Arrangement (CCSA) 

• Direct Inward Dialing (DID) 

• Ontral Office (CO) 

• TIE trunks (TIE) 

• Paging (PAGE) 

• Dictation (DICT) 

• Recorded Announcement (RAN) 

• Automatic Identification of Outgoing Dialing (AIOD) 

• Centralized Automatic Message Accounting (CAMA). 
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Trunk Status 


Incoming Trunks 


Outgoing Trunks 


Toll Peg Count 


4.22 All Trunks Busy. Only valid for trunk groups with more than 
fte rou^made" 

fn^Tp'r^Ti"® Trunk Peg Count. If a path is eligible to be included 
*‘'“"”‘'8 Peg Counu then the Incoming Trunk Peg Count 
for the appropriate trunk group is also incremented. 

“ P** is PiigiWe to be included in 
TFCMl. Incoming Usage, then the usage is also added to Incoming 
Trunk Usage for the appropriate trunk group. ° 

^ is siigiWe to be included 
0“t8?'"8 P«8 Cotnt. then Outgoing Trunk Usage is also 
incremented for the appropriate trunk group. 

if ® P®"’ is eligible to be included in 
TFCOOl, Outgoing Usage, then the usage is also added to Outgoing 
Trunk Usage for the appropriate trunk group. ^ ^ 

4.27 Outgoing Trunk Overflow. Incremented when a request for a 
yunk on this group fails, there being no idle, enabled trunk available 

?! A Dc‘®f ii’® '■®fl“®st may continue through 

(e.g., the ARS feature) to search other routes for an idle trunk. If a 

f completion to that trunk is not possible 

fncrementS'^^^^ blocking, then Outgoing Trunk Overflow is not 

Note 1: Outgoing trunk connections are not considered complete 
until the End-Of-Dialing (EOD) timer expires after the last digit 

^ connections of less than 

the EOD timer will not accumulate traffic data as complete 
connections. End of dialing may be forced bv dialine an 
octothorpe (#). In this case the EOD timer is superceded. 

Note 2: If an outgoing trunk call is disconnected before the EOD 
timer expires, TFSOOl usage will be accumulated, TFSOOl nee 
count, TFCOOl and TFC002 will not be incremented. 

4.28 Only valid for CO and FEX routes. Incremented when the first 
meanmgful digit dialed after the access code is either a ‘O' or a ‘1’ A 
meaningful digit is one that is not absorbed by either the SL-1 or bv 

measurement is incremented as soon 
meaningful digit is dialed. Even if it is abandoned directly 
^ meaningful digit, the Toll Peg Count will still have been 

nnmw' V therefore, to get Toll Peg Count in excess of the 

number of completed outgoing calls. 
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Table 4-B 

TFC002 TRUNKS " FORMAT AND EXAMPLE 


FORMAT: 


System ID TFC002 


Customer Number 


Group Number 

Trunk Type 

Trunks Equipped 

Trunks Working 

Incoming Usage 

Outgoing Usage 

Outgoing Overflow 

Toll PC 

Incoming PC 
Outgoing PC 

All Trunks Busy 

EXAMPLE: 


200 TFC002 



07 


r" 


004 

CO 

00008 

00007 

0000051 

00043 

0000004 

00004 

00000 

00000 

00006 



Note: In Generic XU, the customer number is expressed as a 
3-digit number. 


TFC003 QUEUE 4.29 Timing measurements for TFC003 (Table 4-C) are accumulated in 

the SL-1 in units of 2 s. They are printed in units of 0.1 s, being the 
average taken over a reasonable number of calls. If traffic data is taken 
over a small number of calls (e.g., less than 10), then the accuracy of 
the data will suffer accordingly. 

4.30 Average Attendant Response. This is the average time elapsed 
between a call being presented to an attendant console and the 
attendant answering it If the attendant answers a different call via the 
ICI keys, then the time is accumulated as if the call answered was the 
one first presented (i.e., the measurement still gives a true indication of 
the attendant’s response). 

4.31 Average Time in Queue. This is the time that calls spend in the 
attendant queue averaged over all calls that are placed into that queue. 
Timing starts when the call is placed into the queue. If a call is 
presented to the attendant but a different call is selected via the ICI 
keys, then the time accumulated is adjusted as if the selected call had 
been presented in the first place. 
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4.32 Average Speed of Answer (ASA). This is the time that a call 
waits after its request to terminate at an attendant is recognised by the 
system and before it is answered. It is calculated by the followine 
formula: ® 


ASA = [ (calls delayed x average time in queue)/total calls 1 + 
average attendant response. 

Note 1: The percentage of the total calls that have to enter the 
attendant queue are not recorded. TTierefore, no correlation 
between Average Speed of Answer. Average Attendant Response 
and Average Time in Queue can be made. 

Note 2: Total calls include all incoming calls, dial ‘O’, and recalls. 
Example: 

Customer 3, 4th. of October, 9:00 
Peg Count in queue = 2 
Average time in queue = 3 s 
Average attendant response = 2.4 s 
Total calls = 9 

ASA = (2x3)/9 + 2.4 = 3.1 s. 

4.33 Peg Count of Calls Delayed. Incremented whenever a call is 
removed from the attendant queue. If a call is removed from the queue 
and is presented but then is replaced into the queue because a second 
call has b^n selected via an ICI, this measurement is only incremented 
once as if the first call had remained in the queue throughout. 
Abandoned calls do not increment this count, whether they abandon 
while in the queue dr after they are presented. 

4.34 Peg Count of Abandoned Calls. Incremented whenever a call 
abandons before being answered by the attendant. 

4.35 Average Waiting Time of Abandoned Calls. The average time 
that a call counted in Peg Count of Abandoned Calls waited before 
abandoning. 

Note: For systems equipped with the Centralized Attendant 
Service (CAS) remote feature (Generic X05 and later), TFC003 
measurements are also kept for RLT. The measurements for the 
local attendant(s) at the remote location and the RLT are 
combm^l(m) TFC003. (The CAS feature is described in 
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Table 4-C 


TFC003 QUEUE “ FORMAT AND EXAMPLE 


FORMAT: 


System ID TFC003 


Customer Number 


(Avg. Speed of Answer) 

(Avg. Attendant Response) 

(PC of Calls Delayed) 

(Avg. Time in Queue) 

(PC of Abandoned Calls) 

(Avg. Wait Time of 

Abandoned Calls) 

EXAMPLE: 


200 TFC003 


03 


00092 00048 

00006 00129 

00003 00135 


Note: In Generic Xll, 
number. 

the customer number is expressed as a 3-digit 


TFC004 CONSOLE 4.36 These measurements (Table 4-D) relate to calls handled by the 

attendants. If a call is answered by the attendant and extended then, if 
that call returns to an attendant as a recall it appears as a new call as 
far as this set of measurement is concerned. (Should it involve a trunk 
then it will count as only one call under TFCOOl and TFC002). 

4.37 Total Time Spent Servicing Internal Requests. This is the 
total time, in units of 1 CCS, that an attendant has calls that originated 
within the SL-1 system active on the console, i.e., internal or outgoing 
calls. The time is accrued when such a call is removed from or held on 
the console. A held call will start accumulating further time when it is 
reactivated. 

4.38 Peg Count of Internally Originated Calls Handled by 
Attendant. This measurement is incremented when the call is finally 
removed from the console. It includes calls originated by the attendant. 

4.39 Total Time Spent Servicing External Requests. This is the 
total time, in units of 1 CCS, that an attendant has calls that originated 
outside the SL-1 system active on the console, i.e., incoming calls. The 
time is accumulated when such a call is removed from or held on the 
console. A held call starts to accumulate further time when it is 
reactivated. 

4.40 Peg Count of Externally Originated Calls Handled by 
Attendant. A count of all incoming calls answered by the attendant. 
The measurement is incremented when the call is finally removed from 
the console. 
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4.41 Total Time Spent Servicing Calls. Total Time Spent Servicine 

Internal Requests plus Total Time Spent Servicing External Requests 
the ^ CCS. because of rounding in 

4.42 Total Time Console is Manned. The total time that the console 
was neither in Night Service nor Position Busy. Although a console is in 
Night Service or Position Busy, a call at present on the console can still 
be completed and, therefore, accumulate time. Also, new calls can still 
be originated by the attendant from the console. It is therefore possible 
^ have a Total Time Spent Servicing Galls Greater than Total Time 
Console IS Manned. 


4.43 Number of Times All Attendant Loops are Busy. Incremented 
whenever the last attendant loop on the console is made busy. 

4.44 One output is provided for each attendant. Data includes peg 
count and work time. ‘Total time’ measurements are expressed in CCS. 
Internal calls include those originated by the attendant. 

4.45 The total time spent servicing calls may not exactly equal the sum 
of the total times spent servicing internal and external requests due to 
rounding (e.g., 1.3 and 1.4 both round down to 1, but their sum, 2.7, 
rounds up to 3). The total time a console is manned equals the total 
time the console is NOT in Night service and is NOT Position Busy. A 
position busy console may make outgoing calls and complete any 
incoming call presented to the console before the console was made 
position busy. 
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Table 4-D 

TFC004 CONSOLE " FORMAT AND EXAMPLE 



FORMAT: 

System ID TFC004 

Customer Number 

(PC of Internally Originated 
Calls Handled by Attendant) 

(PC of Externally Originated 
Calls Handled by Attendant) 
(Total Time Console is Manned) 
(Number of Times all Attendant 
Loops are Busy) 

EXAMPLE: 

200 TFC004 

00 

02 

00008 0000002 

00025 0000004 

0000015 0000005 

00000 


(Total Time Spent Servicing 
Internal Requests) 

(Total Time Spent Servicing 
External Requests) 

(Total Time Spent Servicing 
Oils) 


Note: In Generic XU, the customer number and attendant number are expressed as 3-digit 
numbers. 


TFC005 FEATURES 4.46 These measurements (Table 4-E) apply only to features activated 

by keys on either an SL-1 set or an attendant console. Features 
activated by code dialing on either 500 or 2500-type sets are not 
included. 

4.47 Auto Dial, Call Forward and Speed Calling are incremented once 
per operation of the feature but not when the feature is reprogrammed. 

4.48 Call Pickup, Clall Transfer, (2all Waiting, Ring Again, Manual 
Signaling, Override, Privacy Release, Attendant Recall, Voice <3all. 
Volume Control, Busy Verify, Barge In, Private Line Service, Call 
Selection and Stored Number Redial are each incremented once per use 
or attempted use of the feature. 

4.49 Three-party Conference and Six-party Conference are 
incremented once for each new conferee added to the conference (e.g., 
a 5-party conference pegs three times, once for each conferee add^ to 
the original two parties). 

4.50 A peg count is given for each feature for one specified customer. 
Each line of output is a feature. Features are identified by number (see 
Table 4-F). 
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Table 4-E 

TFC005 FEATURES " FORMAT AND EXAMPLE 

——ZZZZIZIZ^^ ^ ^ 

FORMAT: 

System ID TFC005 
Customer Number 


(Feature Number) (Peg Count) 

EXAMPLE: 

200 TFC005 

00 

00 00012 

01 00002 

02 00003 

03 00015 

04 00002 

05 00000 

etc. 

Note: In Generic XI1, the customer number and feature number 
_ are expressed as 3-digit numbers. 


Table 4-F 

TFC005 FEATURE KEY NUMBERS 




NUMBER FEATURE 


NUMBER FEATURE 


00 

01 

02 

03 

04 

05 

06 

07 

08 

09 

10 

11 

12 

13 

14 

15 

16 


Auto Dial 

17 

Call Forward 

18 

Call Pickup 

19 

Call Transfer 

19 

Call Waiting 

20 

3-Party Conference 

20 

6-Party Conference 

21 

Manual Signaling 

21 

Override 

22 

Privacy Release 

22 

Private Line Service 

23 

Ring Again 

24 

Speed Call 

25 

Voice Call 

26 

Volume Control 

27 

Busy Verify 

28 

Barge In 

29 


30 


Call Selection (ICI) 

Attendant Recall 
Dial Intercom 
Message Center INCALLS 
(X07) 

SL-1 Set Message Waiting 
Attendant Message 
Indication (X07) 

SL-1 Set Message Indication 
(X07) 

Message Indication 

SL-1 Set Message Waiting (X07) 

Message Cancellation 

Message Center INCALLS 

Attendant Overflow 

Group Call 

Auto Answerback 

spare 

spare 

Call Park 

Stored Number Redial 
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Table 4-F Continued 

TFC005 FEATURE KEY NUMBERS 


NUMBER FEATURE NUMBER FEATURE 


Note: The feature number (01, 07, etc.,) is increased by a single digit (001, 007, etc.,) in Generic 

Xll. 


TFC006 ARS 4.51 These measurements (Table 4-G) give the number of calls dealt 

QUEUING/RGA with by the ARSQ and the Ring Again (RGA) feature. Measurements 

are accumulated for each ARSQ code, and also for each Routing, if the 
call involved the ARS package. 

Note: ARS is replaced by BARS/NARS in Generic Xll. TFC006 
data is, therefore, neither accumulated nor printed on systems 
quipped with Generic Xll. Traffic data related to BARS/NARS 
is identified in Network Traffic Measurements. 

4.52 ARS Originations. This item is a peg count of each fully dialed 
ARS call that successfully translated to a Routing. 

4.53 ARS immediate Terminations. This item is a peg count of each 
ARS call that terminated immediately (i.e., upon dialing an ARS access 
code) or terminated after an ARS pause timeout (i.e., after waiting T 
seconds as specified for the DELY prompt of overlay 27). 

4.54 RGA Cancellations. This item is a peg count of each call that 
activated RGA and then was cancelled (either by the system or by the 
user). 

4.55 RGA Cancellation Wait. This item is the average time spent in 
the RGA queue by a call waiting to access a trunk. The timing 
measurement is accumulated in units of 2 s. It is printed in units of 0.1 
s, which is the average taken over the number of calls. If traffic data, is 
taken over a small number of calls, then the accuracy of the data will 
suffer accordingly. 

4.56 RGA Acceptance. This item is a peg count of each call that 
activated RGA and subsequently accepted the call offered by the 
system. 

4.57 RGA Acceptance Wait. This item is the average time spent in 
the RGA queue by a call waiting to access a trunk. The value is 
expressed in units of 0.1 s. 

4.58 RGA Expensive Route Wait Timeouts. This item is a peg count 
of each call that activated RGA and whose Expensive Route Wait Timer 
expired. 

4.59 ARS Totai Terminations. This item is a peg count of each ARS 
call that eventually terminated. The termination may have been 
immediate (i.e., after the ARS access code was dialed), after the ARS 
pause timeout or via the operation of RGA. Peg counts are also kept on 
a trunk route basis for each Routing. 
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4.60 The output is a breakdown over ARSQ codes (0 to 3), over 
defined Routings (0 to 255) and over associated routes of a Routing for 
the ARS Total Terminations peg. There is no breakdown over individual 
traffic items. 

4.61 Each line of output is identified by a mnemonic: QC for ARSQ 
code, SB for Routing and RT for a route of a Routing. The ordering of 
the output is all ARSQ codes scheduled for printing followed by all 
Routings sheduled for printing. Each Routing is followed by the route 
breakdown for the ARS Total Termination peg. 
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Table 4-G 

TFC006 ARSQ/RGA “ FORMAT AND EXAMPLE 


FORMAT: 

System ID TFC006 
Customer Number 

QC(ARSQcode) (a) (b) (c) (d) (e) (f) (g) (h) 


SB (Routing number) (a) (b) (c) (d) (e) (f) (g) (h) 
RT (route number) (PC of terminations) 


where: 

(a) “ PC ARS Originations 

(b) “ PC of ARS Immediate terminations 

(c) “ PC of RGA Cancellations 

(d) - Average time of RGA Cancellations 

(e) - PC of RGA Acceptances 

(f) - Average time of RGA Acceptances 

(g) - PC of RGA Expensive Route Wait Timeouts 

(h) - PC of ARS Total Terminations 

EXAMPLE: 

200 TFC006 
00 


QC 

0 

00005 

00003 

00001 

00200 

00001 

00600 

00001 

00004 

QC 

2 

00002 

00002 

00000 

00000 

00000 

00000 

00000 

00002 

SB 

001 

00004 

00001 

00000 

00000 

00003 

00300 

00002 

00004 


RT 01 00001 

RT 14 00001 

RT 15 00002 


TFC007 SYSTEM PARK 4.62 These measurements (Table 4-H) provide the statistics related to 

(Generic X07) the usage of the system park feature of Generic X07. 

4.63 System Park Usage Peg Count. Incremented each time a call is 
parked on a system park number. Recalls which are returned to system 
park are not included. 

4.64 Park Overflow Peg Count. Incremented each time a park 
number is requested and no park number is available. 

4.65 System park Recalls. Incremented each time a parked call is 
presented to an attendant as a recall. 
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4.66 Average Wait Time of System Park Number. This is the 
average time that calls wait on system park numbers. The time includes I 

calls that are abandoned, pickup up by the paged party or released bv ^ 

the attendant on recall. The value is expressed in units of 0.1 s. 

Table 4-H 

TFC007 SYSTEM PARK - FORMAT AND EXAMPLE 


FORMAT; 

System ID TFC007 
Customer Number 

(Usage Count) (Overflow PC) (Recall PC) (Avg. Wait Time) 
EXAMPLE: 

200 TFC007 
00 

00002 00009 00003 00157 


TFC007 CALL PARK 
(Generic XII, X37) 


4.67 Traffic measurement data is accumulated for the following items 
related to usage of the Call Park feature (Table 4-1). 

4.68 System Park Usage. This count identifies the number of calls 
that were parked to a System Park DN. 

4.69 Station Park Usage. This count identifies the number of calls 
that were parked to a Station Park DN. 

4.70 System Park Overflow. This count identifies the number of 
calls that could not be parked because a Svstem Park DN was not 
available. 


4.71 Parked Access. This count identifies the number of parked calls 
that were successfully accessed. 

4.72 Park Recall. This count identifies the number of parked calls that 
were recalled after the Call Park Recall Timer (service changeable) 
expired. 

4.73 Average Wait for Access. This value (expressed in units of 0 1 
s) reflects the average time that parked calls waited before being 
accessed. 
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Table 4-1 

TFC007 CALL PARK - FORMAT 


System ID TFC007 
Customer Number 

flaaflfl bbbbb ccccc ddddd eeeee fffff 

where, 

a = system park usage count 
b = system park overflow count 
c = station park usage count 
d = parked call access count 
e = parked call recall count 
f = average wait time in park (in units of 0.1s). 


TFC008 INTEGRATED 4.74 The traffic control program (overlay 02) is modified to enable 

MESSAGING SYSTEMS traffic measurement ^ data related to usage of the IMS and IVMS 

features (553-2781-100 and 553-2881-100) to be accumulated and 
printed (Table 4-J). A new customer option number, ‘8’, is used in 
conjunction with the SOPC command to select the IMS/IVMS traffic 
measurement option. 

4.75 Measurements for the Telephone Status feature, Telephone Set 
Messaging feature, IMS Message Attendant and IVMS call processor are 
accumulated for each ACD-DN (i.e., message center DN), while the 
Auxiliary Processor Link (APL) statistics are accumulated for each APL. 
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Table 4-J 

TFC008 IMS/IVMS - FORMAT 


System ID TFC008 
Customer Number 
APL 


APL# 

OUTQ 

INPQ AVGOQ 

AVGIQ DOWN 

OCR 

ICR 


OVFL 

OVFL SIZE 

SIZE TIME 

UAV 

UAV 

OMSG 

MSGO 

MSGl 

MSG9 




MSGIO 

MSGll 

MSG19 



IMSG 

MSGO 

MSGl 

MSG9 




MSGIO 

MSGll 

MSG19 




NAK CHAR 

UNSYNC 


PACKET XXXXX 


MAQ 

ACD-DN QLNGTH MADRCT MAINDRT ABNDN ABNDN AVG DCP PCP 

AVG DLY 
WAIT 

TST 

ACD-DN TOTAL SPRE CFW UST FAIL 
CALLS 


TMG 


ACD-DN QLNGTH 

TOTAL 

CALLS 

SUCC ABNDN FAIL AVG MARQST 

TLME 

where. 



(a) APL 



APL# 

= 

the number of the APL 

OUTQ OVFL 

= 

output queue overflow 

INPQ OVFL 

= 

input queue overflow 

AVFOQ SIZE 

= 

average output queue size 

AVGIQ SIZE 

= 

average input queue size 

DOWN TIME 


total APL down time in seconds 

OCR UAV 

= 

output message call register unavailable 

ICR UAV 


input message call register unavailable 

TO 

= 

total timeout count 

NAK 

= 

total number of negative acknowledgements 
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Table 4-J Continued 
TFC008 IMS/IVMS - FORMAT 





( 


CHAR UNSYNC 
OMSG 
IMSG 
PACKET 

(b) MAQ 
ACD-DN 
QLNGTH 

MADRCT 

MAINDRT 

ABNDN 
AVG WAIT 
AVG DLY 
DCP 
PCP 

(c) TST 
ACD DN 
TOTAL CALLS 
SPRE 

CFW 

UST 

FAIL 

(d) TMG 


= input characters out of synchronization 
= output message traffic count (by message type) 

= input message traffic count (by message type) 

= output packeted message count 

= the ACD-DN being reported 

= total number of calls in the message attendant queue or VMS 
processor queue 

= total number of direct calls to the message attendant or VMS 
processor queue 

= total number of indirect calls to the message attendant or VMS 
processor queue 

= total number of calls to this ACD-DN that were abandoned before 
being answered 

= the average time (in seconds) that calls waited before being 
abandoned 

= the average delay = total waiting time for all calls divided by the 
number of calls answered for this ACD-DN 

= direct call processing time: average time (in seconds) that each 
message attendant spent handling answered calls to this ACD-DN 

= post call processing: average time (in seconds) that each message 
attendant or VMS processor was ‘not ready’ per answered call to this 
ACD-DN. 

= identification of ACD DN reported 
= the total number of Telset status calls 
= total number of Special Prefix access calls 
= total number of call forward access calls 
= total number of user status key access calls 
= total number of unsuccessful Telset status calls 
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Table 4-J Continued 
TFC008 IMS/IVMS - FORMAT 



QLNGTH 
TOTAL CALLS 
SUCC 
ABNDN 
FAIL 

AVG TIME 


total number of calls Queued for the message attendant 
= total number of Telset messaging calls 
= total number of successful Telset messaging calls 
= total number of abandoned Telset messaging calls 
= total number of unsuccessful Telset messaging calls 
= average Telset messaging processing time in seconds 
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5. CUSTOMER NETWORK TRAFFIC MEASUREMENT OUTPUTS 


5.01 Network traffic measurements are available at an SL-1 switch 
equipped with the Network Traffic (NTRF) feature of Generic XU. 
The measurements pertain to the following Generic XU features: 

• Basic Alternate Route Selection (BARS) - 553-2751-100 

• Network Alternate Route Selection (NARS) ” 553-2751-100 

• Network Queuing Features “ 553-2751-101 

• Coordinated Dialing Plan (CDP) - 553-2751-102. 

TFNOOl ROUTING 5.02 A route list is a list of outgoing alternate trunk routes to a specific 

MEASUREMENTS location from an SL-1 switch. Trunk routes in a route list are termed 

route list entries. The number of route lists/entries that can be defined 
at an SL-1 switch depends on the features equipped at that switch. 
Table 5-A lists the parameters for the different features and feature 
combinations. 

Table 5-A 

SUMMARY OF SL-1 NETWORKING FEATURE PARAMETERS 


FEATURES EQUIPPED AT SWITCH 


PARAMETER 

BARS 

NARS 

CDP 

CDP WITH 
BARS 

CDP WITH 
NARS 

NCOS Groups 

0-3 

0-15 

0-3 

0-3 

0-15 

Facility Restriction 

0-7 

0-7 

0-7 

0-7 

0-7 

Digit Manipulation 

Tables 

1-255 

1-255 

1-31 

1-255 

1-255 

Route Lists 

0-127 

0-255 

0-31 

0-127 

0-255 

Route List Entries 

0-7 

0-7 

0-2 

0-7 

0-7 

FCAS Tables 

1-127 

1-255 

- 

1-127 

1-255 

SDR Tables 

0-31 

0-255 

- 

0-31 

0-255 

Steering Codes 

— 

— 

1-5000 

1-5000 

1-5000 


Note 1: NCOS = Network Class-of-Service 
FCAS = Free Calling Area Screening 
SDR = Supplemental Digit Restriction. 

Note 2: If the NARS and BARS features are equipped in the same 
switch but for different customers, the highest parameter values 
apply to that switch: e.g., if one customer has NARS and another 
customer has BARS, the NARS parameters apply to the BARS 
customer. 
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Note 3: If the New Flexible Code Restriction (NFCR) feature is 
equipped in conjunction with either BARS or CDP, the number of 
available NCOS groups is 8 (0 to 7). If the AUTOVON feature is 
equipped with BARS or CDP, 16 (0 to 15) NCOS groups are 
available. 

5.03 The routing traffic measurements (TFNOOl) provide data related to 
route list utilization. The measurements show how often a route list was 
accessed, which entries in the list were used and whether the call was 
successful in completing a selection or connection. Routing traffic 
measurements are available at SL-1 Node and SL-1 Main switches. 

5.04 Routing traffic measurements (Table 5-B) are provided for each 
defined route list at an SL-1 switch. 

5.05 Route List Requests. This measurement identifies the total 
number of attempts (calls) in which the called destination translations 
identified this route list to attempt call completion. The count is 
incremented each time the route list is selected to attempt route 
selection. 

5.06 Route List Requests Served Without Delay. This measurement 
identifies the number of calls which were routed without encountering 
blockage or queuing. The count is incremented when a route list is 
selected and an available trunk is chosen without being offered 
Off-Hook Queuing (OHQ) or Call-Back Queuing (CBQ). The count 
includes expensive route acceptances. 

5.07 Expensive Route Acceptances. This measurement identifies the 
number of times calls were routed over an expensive route choice after 
the caller was informed of the additional cost of the call. The count is 
incremented after a caller receives Expensive Route Warning Tone 
(ERWT) and elects to complete the call over the expensive facility. 

5,08 Route List Requests Standard Blocking. This measurement 
identifies the number of call attempts that could not be served because 
a route or queuing process was not available to the caller. The blocked 
call may have been given overflow tone or recorded announcement, or 
routed to the attendant The count is incremented if: 

• the caller’s Facility Restriction Level (FRL) is not sufficient to select 
any route choice 

• no route choice is available and the caller is only allowed OHQ but 
too many calls are already queued 

• the call times out in the OHQ 

• blocking occurred and the system could not select another route 
choice and neither OHQ nor CBQ is allowed. 

5.09 Route List Entry Usage Count. This measurement identifies the 
number of calls that were successfully routed over a particular route list 
entry (trunk route). A count is maintained for each route list entry. The 
count is incremented when: 

• an entry is selected without being offered OHQ or CBQ 

• an entry is selected after OHQ or OHQ timeout 
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Off-Hook Queuing 
Measurements 


Call-Back Queuing 
Measurements 




• an entry is selected to process a CBQ callback. 

5.10 Traffic measurements for Off-Hook Queuing (OHQ) are associated 
with each route list and identify the utilization of the OHQ feature. 
The OHQ measurements are included with the routing traffic 
measurements (TFNOOl). 

5.11 Quantity of Calls Placed in OHQ. This measurement identifies 
the number of calls which attempted to use a route in the route list but, 
because facilities were not immediately available, the call was allowed to 
remain off-hook to w'ait for facilities. The count is incremented each 
time a call (Note) is placed in the OHQ. 

Note: This measurement includes calls which originated from 
stations at an SL-1 Node, SL-1 Main or Conventional Main, or 
which were made via the Direct Inward System Access (DISA) 
feature. 

5.12 Average Time in OHQ. This measurement identifies the average 
time that calls waited in the OHQ for a facility to become available. 
The time is computed and presented in units of 0.1 s. The queue 
handler obtains a timestamp when a call is placed in the OHQ and when 
it is removed from the OHQ. The time difference is added to an 
accumulating count for the route list only under the following 
conditions: 

• a route becomes avaUable 

• the OHQ time limit expires and the call is removed from the OHQ 

• the caller abandons a call while waiting in the OHQ. 

5.13 Quantity of Calls Abandoned While In OHQ. This measurement 
identifies the number of calls that were placed in the OHQ but were 
abandoned before a route became available or the OHQ time limit 
expired. The count is incremented when a station set an SL-1 Node, 
SL-1 Main or Conventional Main disconnects during the OHQ offer or 
while waiting in the OHQ. 

5.14 Traffic measurements for Call-Back Queuing (CBQ) are associated 
with each route list and identify the utilization of the feature. CBQ 
measurements are included with the routing traffic measurem.ents 
(TFNOOl). 

5.15 Quantity of Call-Back Queued Calls. This measurement 
identifies the number of calls which were offered Call-Back Queuing 
(CBQ), accepted the offer and were placed in the CBQ. The count is 
incremented each time a call is placed in the CBQ. 

5.16 Average Time in CBQ. This measurement identifies the average 
duration calls remained in the CBQ. The measurement is incremented 
when a local station has accepted the CBQ offer and is placed in the 
CBQ. 

5.17 The queue handler obtains a tim^tamp when a call is placed in the 
CBQ and when it is removed from the CBQ. The time difference is 
added to the accumulating count for the route list. Output is in units of 
0.1 s. 
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5.18 Quantity of CBQ Offerings. This measurement identifies the 
number of CBQ calls that were offered CBQ callbacks regardless of 
whether the CBQ callback was answered. The count is incremented 
when the caller is presented with the CBQ callback. 

5.19 Quantity of CBQ User Canceliations. This measurement 
identifies the number of CBQ calls that were removed from, the CBQ at 
the user’s request. The count is incremented when: 

• a local station (500/2500-type set) dials the Ring Again cancellation 
code 

• a local station (SL-1 set) depresses the Ring Again feature key when 
the associated lamp is steadily liL 

Note: Only those calls actually found in the CBQ and removed are 
counted. 

5.20 With Generic Xll Release 3, traffic measurements for the SL-1 
Tone Detector (SLITD) are included in the TFNOOl message. The peg is 
incremented when a trunk is seized but released when alternate routing 
is performed during a call involving an SLITD. 
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Table 5-B 

TFN001 ROUTING “ FORMAT 


System ID TFNOOl 
Customer Number 


XXX 

aaaaa 

bbbbb 

ccccc 

ddddd 

eeeee 

fffff 

RT 

ggggg 

ggggg 

ggggg 

ggggg 

ggggg 

ggggg 


PPPPP 

PPPPP 

PPPPP 

PPPPP 

PPPPP 

PPPPP 

OHQ 

hhhhh 

iiiii 

jjjjj 




CBQ 

kkkkk 

mil 

mmmmm 

nnnnn 




ggggg 


ggggg 


where. 


a = route list requests 


b = route list requests served without delay 
c = expensive route acceptances 


d = route list requests standard blocking 
e = not defined (all zeros) 


f = not defined (all zeros) 

g = route list entry usage count for each entry in the route list 
h = quantity of calls placed in OHQ (Note) 
i = average time in OHQ (units of 0.1 s) 
j = quantity of calls abandoned from OHQ 


k = quantity of CBQ calls (Note) 

1 = average time in CBQ (units of 0.1 s) 


m = quantity of CBQ offerings 
n = quantity of CBQ user cancellations 

p = quantity of calls involving SLITD on which alternate routing was performed during the call 
X = route list number 

Note: OHQ and/or CBQ information is printed only if the feature is equipped and activated. 
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TFN002 NETWORK 

CLASS-OF-SERVICE 

MEASUREMENTS 


5.21 Traffic measurements are collected for each defined NCOS group 
(0 to 15) to indicate the grade of service, in terms of blocking and 
queuing delay, being provided by the system. If a grade of service is 
determined by the communications manager to be appropriate for users 
in a particular NCOS group, then the communications manager can 
either resign the users to another NCOS group, redefine the 
characteristics of the existing NCOS group or change the routine 
parameters (see Table 5-C). 

5.22 Quantity of Calls Received. This measurement identifies the 
total number of network call attempts generated by users assiened to 
this NCOS group. 

5.23 Routing Requests Served Without Delay. This measurement 
identifies the number of call attempts that were routed without 
encountering blockage or being offered queuing. 

5.24 Expensive Route Acceptances. If the NCOS group is defined 
to provide an Expensive Route Warning Tone (ERWT) to the call 
originator when an expensive route is selected for call completion, the 
count is incremented if the user allows the call to complete over the 
expensive facility after having received the ERWT. 


5.25 Network Cali Standard Blocking. This measurement identifies 
the number of call attempts, by users in this NCOS group, that could 
not be served because a route or queuing process was not available to 
the user. 

5.26 Calls Refusing Expensive Routes. This measurement identifies 
the number of callers that received ERWT and either abandoned the 
call or activated the Ring Again feature to place the call in the 
Call-Back Queue. 

5.27 Quantity of Calls Placed in OHO. This measurement identifies 
the number of calls, generated by users in this NCOS group, that were 
offered Off-Hook Queuing (OHQ) and accepted the offer. 

5.28 Average Time in OH^ This measurement identifies the average 
duration that calls remained in the OHQ. The time is expressed in units 
of 0.1 s. (Calls which time out in the queue are included in the average.) 

5.29 Quantity of CBQ calls. This measurements identifies the number 
of calls that were offered Call-Back Queuing (CBQ) and accepted (i.e. 
invoked Ring Again) the offer. 

5.30 Average Time in CBQ. This measurement identifies the average 
time (in units of 0.1 s) that calls in this NCOS group waited in the CBQ 
for an available route. The measurement includes calls which requested 
a CBQ cancellation, calls which were completed and calls that initiated 
direct Ring Again against trunks. 
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Table 5-C 

TFN002 NCOS " FORMAT 


System ID TFN002 
Customer Number 

NCOS XXX aaaaa bbbbb ccccc ddddd eeeee fffff 
OHQ gg^g hhhhh 

CBQ iiiii jjjjj 

where, 

a = quantity of calls attempted 
b = routing requests served without delay 
c = expensive route acceptances 
d = network call standard blocking 
e = not defined (all zeros) 
f = quantity of calls refusing expensive routes 
g = quantity of calls placed in OHQ (Note) 
h = average time in OHQ (in units of 0.1 s) 
i = quantity of CBQ calls (Note) 
j = average time in CBQ (in units of 0.1 s) 

X = network class of service group 

Note: OHQ and/or CBQ information is printed only if the feature is 
equipped and activated. 


TFN003 INCOMING 5.31 The Incoming Trunk Group (TFN003) measurements (Table 5~D) 

TRUNK GROUP provide an indication of the incremental traffic that was imposed on 

MEASUREMENTS incoming trunk groups by the network queuing features. Data are 

provided for each incoming or 2-way trunk group that is offered OHQ, 
CCBQ or CBCJCM. These measurements are available at SL-1 Node and 
SL-1 Main switches. 

5.32 Quantity of Calls Placed in OHQ. This measurement identifies 
the number of incoming trunk calls that were placed in the OHQ for 
possible connection to another trunk group. 

5.33 Average Time in OHQ. This measurement reflects the average 
time (in units of 0.1 s) that calls waited in the OHQ for a trunk to 
become available. The average time includes those calls that were 
removed from the OHQ by caller abandonment or were removed from 
the queue after expiration of the OHQ time limit 
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5.34 Quantity of Incoming Calls Offered CCBQ or CBQCM. This 
measurement identifies the number of incoming trunk calls that were 
blocked at the SL-1 Node and the user was given the option of 
accepting an SL-1 Node initiated callback when facilities become 
available. The measurement relates to use of the CBQ feature by users 
at an SL-1 Main (Coordinated Call-Back Queuing) or Conventional 
Main (C^ll-Back Queuing for Conventional Mains). 

5.35 Quantity of Calls Accepting CCBQ or CBQCM. This 
measurement identifies the number of incoming trunk calls that were 
blocked at the SL-1 Node, were offered CBQ and accepted the offer. 
The count relates to CBQ acceptances by users at an SL-1 Main or 
Conventional Main. 

5.36 Average Time in CBQ. This measurement (expressed in units of 
0.1 s) reflects the average time that users at an SL-1 Main or 
Conventional Main remained in the CBQ (at the SL-1 Node) for a 
facility to become available. 

Note 1: When a CCBQ callback is offered to a busy station at an 
SL-1 Main, the call is removed from the queue for 5 minutes then 
reinserted in the queue. This process occurs only once. The 
additional queuing time is added to the average time. The 5 minute 
suspension time is not included in the average time, nor is 
reinsertion into the queue pegged as another CBQ call. 

Note 2: When a CBQCM callback is offered to a station at a 
Conventional Main that is busy or fails to answer the callback, the 
call is removed from the queue and reinserted into the queue as 
specified in Note 1. 

5.37 Quantity of Calls Blocked in Callback. This measurement 
identifies the number of CBQ callbacks (CCBQ or CBQCM) initiated by 
the SL-1 Node that could not be completed because an outgoing trunk 
group (to the SL-1 Main or Conventional Main) was not available. 

5.38 Callback Attempts No Answer and Cancellation. This 
measurement identifies the number of callback attempts that were not 
successful because the caller failed to answer the callback. CBQ 
callbacks to a station at an SL-1 Main that has previously cancelled 
CBQ are treated as callback attempts no answer. 








Page 5-8 



PRACTICE 553-2001-450 


Table 5-D 

TFN003 INCOMING TRUNK GROUP “ FORMAT 


System ID TFN003 

Customer Number 

TRKG XXX 

OHQ aaaaa bbbbb 

CBQ ccccc ddddd eeeee fffff ggggg 

where, 

a = quantity of calls placed in OHQ 
b = average time in OHQ (in units of 0.1 s) 
c = quantity of incoming calls offered CBQ (CCBQ or CBQCM) 
d = quantity of calls accepting CBQ offer (CCBQ or CBCJCM) 
e = average time in CBQ (in units of 0.1 s) 
f = quantity of blocked CBQ callbacks (CCBQ or CBQCM) 
g = quantity of callback attempts not answered or cancelled 
X = incoming trunk group number (0 to 127) 


5.39 The Off-Hook Queue (OHQ) overflow threshold measurement 
provides an indication that more than the expected number of users are 
timing out in the OHQ. This means that OHQ is offered and accepted 
but a trunk does not become available before the service-changeable 
OHQ time limit expires. This could result from trunks being out of 
service, an incorrectly defined OHQ time limit or temporary traffic 
overload. 

5.40 OHQ Overflow Threshold Format. 

System ID TFNIOI 
Customer Number 

OHQT aaaaa bbbbb 

where, 

aaaaa = the number of OHQ calls which timed out (overflowed) in the 
OHQ before an available trunk was found. 

bbbbb = the threshold. This value (expressed in units of 0.1 percent) 
represents the total number of OHC) overflow, divided by the total 
number of OHQ offers plus the OHQ overflows. 


TFNIOI OHQ 

OVERFLOW 

THRESHOLD 
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6. THRESHOLD VIOLATION OUTPUTS 


6.01 The outputs described here are given only when threshold levels 
are exceeded. The measurements are checked against the threshold levels 
and the specified traffic schedule for that system or customer. 
Threshold violations trigger the associated system and customer 
measurements to be output, whether or not these measurements are 
scheduled to be output. Not setting a threshold is equivalent to setting it 
to zero and may result in an exception report 

TFSIOI DIAL TONE 6.02 A threshold level set on the percentap of all calls that experience 

SPEED dial tone delay in excess of 3 s expressed in units of 0.1%. Also output 

when a threshold violation occurs are: 

• TFS002 " Services 

• TFS003 ” Dial Tone Delay 

• TFS004 “ Processor Load. 

6.03 Dial Tone Speed Threshold Format. 

System ID TFSIOI 

(Percent Dial Tone Delay) (Threshold) 

6.04 Example. 

200 TFSIOI 
00017 00015 

TFS102 LOOP TRAFFIC 6.05 This is a threshold level, expressed in CCS, set on the loop usage 

per measurement period. Also output when a threshold violation occurs 
is TFSOOl, Networks. The threshold is set for all loops and cannot be 
set on a loop basis. 

6.06 Loop Traffic Threshold Format. 

System ID TFS102 

(Loop Number) (Loop Usage) (Threshold) 

6.07 Example. 

220 TFS102 
01 0000550 00450 

TFS105 JUNCTOR 6.08 This is the threshold level, expressed in CCS, set on the junctor 

TRAFFIC usage per measurement period. When the junctor traffic threshold is 

exceed, TFS007 Junctor Traffic is printed. The threshold is same for 
all junctor groups and cannot be set on a junctor group basis. 

6.09 Junctor Traffic Threshold Format. 

System ID TFS105 
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TFC101 INCOMING 
MATCHING LOSS 


TFC102 OUTGOING 
MATCHING LOSS 


(Junctor Group) (Junctor Usage) (Threshold) 

\ 

6.10 Example. 

222 TFS105 

13 0002341 0002000 

6.11 This is a threshold level set on the percentage of incoming calls 
where a failure to match occurs while attempting to set up a connection 
between an incoming trunk and a called line or the attendant, or the 
attendant fails to extend the call due to a failure to match. It is 
express^ in units of 0.1%. Also output when a threshold violation 
occurs is TFSOOl, Networks. 

Note: When an incoming call is not presented to an attendant due 
to a failure to match, it is included in the Incoming Matching Loss 
(IML) figure but it is not necessarily lost. The call is placed in the 
attendant queue and regular attempts are made to present it to an 
attendant when the network permits. A call contributes at most 
one failure to match count to the IML measurement regardless of 
further failures to complete due to failures to match. 

6.12 Incoming Matching Loss Threshold Format. 

System ID TFCIOI 

Customer Number 

(Incoming Matching Loss) (Threshold) ) 

6.13 Example. 

200 TFCIOI 
00 

00014 00010 

6.14 This is a threshold level set on the percentage of outgoing calls 
where a failure to match occurs while attempting to set up a connection 
between a line equipment and an outgoing trunk. It is expressed in units 
of 0.1%. Also output when a threshold violation occurs is TFSOOl, 

Networks. Each outgoing call can be pegged only once for outgoing 
matching loss. 

6.15 Outgoing Matching Loss Threshold Format. 

System ID TFC102 

Customer Number 

(Outgoing Matching Loss) (Threshold) 

6.16 Example. 

200 TFC102 
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1 , ! 


TFC103 AVERAGE 
SPEED OF ANSWER 


TFC104 PERCENT ALL 
TRUNKS BUSY 


00014 00010 

6.17 This is a threshold level set on the average time, in units of 0.1 s, 
that calls wait to be answered by the attendanL Also output when a 
threshold violation occurs are TFC003, Queue, and TFC004, Console. 

6.18 Speed of Answer Threshold Format. 

System ID TFC103 
Customer Number 

(Average Speed of Answer) (Threshold) 

6.19 Example. 

200 TFC103 
00 

00152 00120 

6.20 This is a threshold level set on the percentage of trunk 
connections where the last trunk in a trunk group is made busy. It is 
expressed in units of 0.1%. The All Trunks Busy measurement is only 
made for trunk groups that have more than one member. The equation 
for calculating this threshold is: 

All Trunks Busy Peg Count/(Successful Calls + Overflows) 

Note: Successful calls are defined as those that have been 
answered or reached the established state. All calls except outgoing 
trunk calls are considered successful as soon as they are answered. 
Outgoing trunk calls are considered successful only when the 
End-Of “Dialing (EOD) timer has expired or an octothorpe (#) has 
been dialed to force an end of dialing. 

6.21 Percent All Trunks Busy Threshold Format. 

System ID TFC104 

Customer Number 
Trunk Group 

(All Trunks Busy) (Threshold) 

6.22 Example. 

200 TFC104 
02 

04 

00024 00017 
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6.00 TRAFFIC MEASUREKENT OUTPUTS - OVERVIEW 


GENERAL 


6-01 Traffic data available for output are: 

System Measurements - Accuiuiated on a system basis- 
Customer Measurements - Accumulated on a per customer basis. 
System Threshold Violations - Tests on system measurements. 
Customer Thresholds Violations - Tests on customer measurements. 

Schedules for each type of measurement can be defined independently. 


SYSTEM MEASUREMENTS 


6-02 System measurements are identified by the prefix TFS. The 3-digit 
code following the prefix identifies the type of measurement. 


CODE 

DESCRIPTION 

TFS001 

Networks (per loop) 

TFS002 

Services 

TFS003 

Dial Tone Delay 

TFS004 

Processor Load 

TFS005 

Lines 

TFS007 

Junctor Group Traffic 




CUSTOMER MEASUREMENTS 


6,03 Customer measurements are identified by the prefix TFC. The 
3-digit code following the prefix identifies the type of measurement. 


CODE 

DESCRIPTION 


TFCOO1 

Networks (per 

customer) 

TFC002 

Trunks 

TFCOOS 

Queue 


TFC004 

Console 


TFC005 

Features 

Again 

TFC006 

ARS and Bing 


Vll 




6.04 Feature measurements can only be made on one customer at a time 
for a given system because only one holding area is provided.. This 
customer must he pre-specified in the manner explained in 11,23, 
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THRESHOLD VIOLATION MEASDBEflEHTS 


6-05 Systea threshold levels can be set for: 

a) Dial Tone Speed - Failure to provide dial tone to a set within 
3 seconds of the systea recognizing the seizure of the line. 
Expressed as a percentage of total dial tone requests in units 
of 0.1%. 


b) Loop Traffic - The network loop 
CCS. 


usage per hour. Expressed in 


c) Junctor Traffic - The junctor group usage 
in CCS. 

6 .06 Customer Threshold levels can be set for: 


per hour. Expressed 


a) Incoming Hatching Loss - Failure to natch while attempting to 

set up a connection between an incoming trunk and an idle 
called line. Expressed as a percentage of total ^ incoming 
connections in units of 0.1%. 

b) outgoing Hatching Loss - Failure to natch while attempting to 

N set up a connection between a line equipment and an idle 

outgoing trunk. Expressed as a percentage of total outgoing 
connections in units of 0.1%. 

c) Average Speed of Answer - Average tine in units of 0.1 seconds 
that calls wait to be answered by the attendant. 

d) Percent Last Trunk Busy -Last enabled trunk in a trunk group 
is nade busy (incoming or outgoing) • Expressed as a percentage 
of the total trunk connections in units of 0.1%. 

6 .07 The threshold levels are set when the neasurenent requirements are 
input to the system from a TTY. Part 11 describes how thresholds are set 
and Part 8 shows the format of the outputs. 


) 

j 


LINE TBAFFIC MEASUBEflENT 


6.08 For each network loop a special set of lines and/or trunks may be 
defined. Beside the normal traffic measurements additional peg and usage 
measurements are nade for this set of terminals. Lines and/or trunks to 
be included in this set are given the ITH (Individual Traffic 
Heasurement) class of service and nay be defined to the system via the 
Traffic Control Overlay Program. See Part 11.16. Attendants may not be 
given the ITH class of service. 


) 
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7. MEASUREMENT VERIFICATION 


7.01 A number of cross-reference checks may be made to verify the 
traffic data. Certain of the verifications given here contain a tolerance 
(e.g., ±15%). This is because there are a number of cases where a path 
is reserved but never actually used or is used but is neither a tone and 
digit loop connection nor a part of a completed call under the 
definition of TFCOOl. In these cases TFSOOl usage is accumulated as the 
time slots involved are considered occupied, however, no usage is 
accumulated in either TFCOOl or TFS002, e.g.: 

(a) Ring - No answer. A path is reserved between the two terminals, 
but never used. 

(b) Call waiting ” Abandoned. Again a path is reserved, but not used. 

TFSOOl AND TFCOOl 7.02 The sum of TFSOOl usages on all terminal loops, minus the sum of 

TFSOOl usages on tone and digit loops should equal twice the sum of all 
TFCOOl usages for all customers ±25%. 

TFCOOl AND TFC002 7.03 For each customer the following figures should be within ±2%: 

• TFCOOl, outgoing usage should equal TFC002, outgoing trunk usages 
for all groups 

• TFCOOl, outgoing peg count should equal TFC002, the sum of all 
outgoing trunk peg counts for all groups 

• TFCOOl, incoming usage should equal TFC002, the sum of all 
incoming trunks usages for all groups 

• TFCOOl, incoming peg count should equal TFC002, the sum of all 
incoming trunk peg counts for all groups. 

TFSOOl AND TFS002 7.04 The following figures should be equal within ±15%: 

• TFSOOl, the sum of loop failure to match over all TDS loops should 
equal TFS002, the sum of failure to match over all services except 
Digitone receiver and conference loops 

• TFSOOl, the sum of loop usage over all TFS loops should equal 
TFS002, the sum of service usage over all services except Digitone 
receiver and conference 

• TFSOOl, the sum of loop peg over all TDS loops should equal 
TFS002, the sum of service peg over all services except Digitone 
receiver and conference. 

7.05 The following figures should be within ±2%: 

• TFSOOl, the sum of loop failure to match over all conference loops 
should equal TFS002, failure to match - conference only 

• TFSOOl, the sum of loop usage over all conference loops should equal 
TFS002, service usage “ conference only 
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8. COMMUNICATING WITH SYSTEM 


8.01 The Traffic Control overlay program (Program 02) is used when 
any of the following tasks are to be performed: 

• Query system ID, system time-of-day, traffic schedules, traffic 
options or threshold levels 

• Set system ID 

• Set system time-of-day 

• Change system or customer traffic measurement schedules 

• Change traffic options 

• Change threshold levels 

• Access traffic data in the holding registers. 

ACCESSING THE 8.02 All inputs to the system are made via the teletypewriter (TTY). 

SYSTEM When the Traffic Control program is loaded, the appropriate commands 

are input. Should an error or invalid data be input, the system returns 
an error message (Table 8-C). When the task has been completed, the 
Traffic Control program must be aborted and a background overlay 
program loaded. Maintenance personnel should be notified when the 
system fails to provide the correct responses. 

COMMANDS 8.03 There are four types of commands, each type identified by the 

command’s first letter. The command types are: 

(a) T Commands. Used to query schedules, etc. When these 
commands are input the system automatically outputs a response, 
i.e., RETURN does not need to be depressed. 

(b) S Commands. Used to set schedules, etc. These commands are in 
three parts: an S command name input by the user; a response 
output by the system; and a second input by the user. When the S 
command is input, the system responds automatically with the data 
asked for and then outputs a double dash (—). If the data is to be 
changed, the change is keyed in immediately following this prompt. 
If no changes are necessary, the user depresses the RETURN key. 

(c) C Commands. Used to remove or clear an option. The format is 
similar to that of the corresponding S command. 

(d) I Commands. Used to access data in the holding register. The data 
is output immediately. 

8.04 Note the following points: 

(a) The data fields are separated by a space. No other delimiter is 
necessary and no space is needed following a command name. 

(b) The last parameter of the line may be followed by a carriage 
return which acts as a delimiter as well as terminating the 
command. 
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Abbreviations 


TRAFFIC 

MEASUREMENT 

SCHEDULES 


(c) A period (.) prompt indicates that the system is ready to receive a 
new command from the teletypewriter. 

(d) A double dash (—) prompt is output after an S or C command and 
indicates that the system is now ready to receive data. 


(e) An asterisk (♦) in the command definition indicates that the 
carriage return should be depressed. 

(f) In this practice, the commands input by the user are written in 
upper case and the system responses are written in lower case. 

(g) Table 8-C gives a listing of error messages that can be output while 
using the Traffic Control program. 


8.05 The following abbreviations are used to define the 
fields within a traffic measurement command. 


various data 


sh = start hour 
eh = end hour 
sd = start day 
ed = end day 
sm = start month 
em = end month 
so = schedule options 
tc = threshold codes 
tv = threshold values. 

8.06 Traffic measurement schedules can be set independently for 
system and customer measurements. The schedule options are: 


0 “ No traffic scheduled 


1 ” Hourly, on the hour 

2 - Hourly, on the half-hour 

3 - Half-hourly, on the hour and half-hour. 


8.07 A schedule period runs from the start hour of the start day to the 
end hour of the end day, only on the days of the week specified. 


The start day, the start month, the end day and the end month 
numerical represenUtions of the date. For example, August 17 
entered as 17 8. The days of the W'eek are specified as follows: 


are 

is 


1 = Sunday 


2 = Monday 

3 = Tuesday 

4 = Wednesday 

5 = Thursday 

6 = Friday 
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7 =. Saturday. 

8.09 The start hour and stop hour codes are 1 or 2-digit numbers based 
on the 24 h clock (i.e.. 1:00 p.m. is entered as 13). No half-hour start or 
stop hours are possible. Data is output at all scheduled times within the 
time period including the start and stop hours. 

8.10 Query System Traffic Measurement Schedule. The input 
command structure used to query the system traffic measurement 
schedule is: 

TSHS (sd) (sm) (ed) (em) 

(sh) (eh) (so) 

(d) 

Example: 

.TSHS 25 4 16 7 
12 21 2 
2 3 4 5 6 

8.11 Set System Traffic Measurement Schedule. The input 
command format used to set the system traffic measurement schedule 
is: 

SSHS (sd) (sm) (ed) (em) — (SD) (SM) (ED) EM) 

(sh) (eh) (so) - (SH) (EH) (SO) 

(d) - (D) 

Note: To clear the schedule enter 0. 


Example: 

.SSHS 25 4 16 7 — 1 10 1 12 
12 21 2 — 0 23 1 
2 3 4 5 6 — 1 7 


8.12 Query Customer Traffic Measurement Schedule. The format 
of the command used to query a customer schedule is: 

TSHC (CUSTOMER) (sd) (sm) (ed) (em) 

(sh) (eh) (so) 

(d) 

Example: 

.TSHC 0 16 7 12 5 
12 21 2 
234 


8.13 Set Customer Traffic Measurement Schedule. The format of 
the command to set a customer schedule is: 

SSHC (CUSTOMER) (sd) (sm) (ed) (em) — (SD) (SM) (ED) (EM) 

(sh) (eh) (so) — (SH) (EH) (SO) 

(d) — (D) 
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TRAFFIC 

MEASUREMENT 

OPTIONS 


Note: To clear the schedule enter 0. 
Example: 

•SSHC 0 16 7 14 5 — 1 6 12 6 
12 21 3 — 0 23 3 
2 3 4 5 6 — 1 


8.14 System Measurement Options. The system measurement options 
are; 


Option 1 - 
Option 2 - 
Option 3 “ 
Option 4 - 
Option 5 “ 
Option 7 - 


Networks (per loop) 
Services 

Dial Tone Delay 
Processor Load 
Lines 

Junctor Group Traffic. 


8.15 Customer Measurement Options. The customer measurement 
options are: 

Option 1 “ Networks (per customer) 

Option 2 ” Trunks 
Option 3 ” Queue 
Option 4 ” Attendant Console 
Option 5 ” Features 

Option 6 “ ARSQ/RGA (not applicable in XI1) 

Option 8 ” Integrated Messaging System and Integrated Voice 
Messaging System. 


Note: If no options are currently set, NIL is output by the system. 
If option 5 is to be set for a customer then the customer must be 
defined via command SCFT. 

8.16 Network Measurement Options. The network measurement 
options (set on a customer basis) are: 

Option 1 ” Route List Measurements 

Option 2 ” Network Qass-of-Service Measurements 

Option 3 “ Incoming Trunk Group Measurements. 

8.17 Query System Traffic Measurement Options. The format of 
this command is: 
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TOPS (options) 

Example: 

.TOPS 3 5 

8.18 Set System Traffic Measurement Options. The format for this 
command is: 

SOPS (options) — (OPTIONS) 

Example: 

.SOPS 3 5 — 2 

8.19 Clear System Traffic Measurement Options. The format for 
this command is: 

COPS (options) — (OPTIONS) 

Example: 

.COPS 2 3 5 — 3 

8.20 Query Customer Traffic Measurement Options. The input 
format for this command is: 

TOPC (CUSTOMER) (options) 

Example: 

.TOPC 0 4 5 

8.21 Set Customer Traffic Measurement Options. The input format 
for this command is: 

SOPC (CUSTOMER) (options) — (OPTIONS) 

Example: 

.SOPC 0 4 5 — 1 

8.22 Clear Customer Traffic Measurement Options. The input 
format for this command is: 

COPC (CUSTOMER) (options) — (OPTIONS)* 

Example: 

.COPC 0 14 5 — 45 

8.23 Set Customer Network Traffic Options. The input command 
structure used to set the network traffic options is as follows. 
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SOPN (CUSTOMER) (options) ~ (OPTIONS) 
Example: 

.SOPN 0 2 — 1 


8.24 Query Customer Network Traffic Options. Use the following 
command to query the network traffic options: 

TOPN (CUSTOMER) (options) 

Example: 

.TOPN 0 12 

8.25 Clear Customer Network Traffic Options. Use this command 
to clear the network traffic options: 

COPN (CUSTOMER) (options) — (OPTIONS) 

Example: 

.COPN 0 12 — 1 


THRESHOLDS 


8.26 Threshold levels can be queried or set for the system or for each 
cmtomer. The system thresholds with their respective codes and ranges 
of values are given in Table 8-A. The customer thresholds with their 
respective codes and ranges of values are given in Table 8-B. 


Table 8-A 

SYSTEM THRESHOLDS 


CODE 

MEASUREMENT 

RANGE 

1 

Dial Tone Speed 

00.0% to 99.9% 

2 

Loop Traffic 

000 to 999 CCS 

3 

Junctor Group 

Traffic 

0000 to 9999 CCS 
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Table 8-B 


rii.QTOMER THRESHOLDS __—-- 

CODE 

MEASUREMENT 

RANGE 

1 

Incoming Matching 

Loss 

00.0% to 99.9% 

00.0% to 99.9% 

2 

Outgoing Matching 

Loss 

00.0 to 99.9 s 

3 

Average Speed of 

Answer 

00.0% to 99.9% 

4 

Percent All Trunks 

5 

Busy 

Percent OHQ 

00.0% to 99.9% 


Overflow 



3 27 Query System Threshold Level. The input formal for this 
command is: 

TTHS (TO (tv) 

Example: 

.TTHS 1 015 

8.28 Set System Threshold Value. The format for this command is: 
STHS (TO (tv) — (TV) 

Example: 

.STHS 1 020 — 015 

8.29 Query Customer Threshold Value. This command formal is: 
TTHC (CUSTOMER) (TO (tv) 

Example: 

.TTHC 0 2 10 

8.30 Set Customer Threshold Value. The command format is: 

STHC (CUSTOMER) (TO (tv) ~ (TV) 

Example: 

.STHC 0 2 10 — 12 
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LINE TRAFFIC 
TERMINALS 


Qu®ry and change the Individual 
Traffic Measurement (ITM) class-of-service for given Terminal 
Numbers (TN). SL-1, 500/2500“type or trunk terminals can have this 
cte-of-service. Terminals with ITM set are included in the groups for 
which Line Traffic Measurements ae recorded. 

8.32 Query Line Traffic TN. The format for this command is: 

TITM 

(tn) 

(tn) 

(tn) 

etc. 


Note: If only the loop number is printed, it means that all 
equipped terminals have ITM set If only the loop and shelf 
numbers only are printed, it means that all equipped terminals on 
the specified shelf have ITM set If the loop, shelf and card 
numbers are printed, it means that all equipped terminals on the 
specified card have ITM set 


Example: 


.TITM 
SHELF 04 0 
LOO? 05 
TN 11 3 4 1 
CARD 13 2 1 
TN 15 1 2 0 

8.33 Set Line Traffic TNs. The format for this command is: 

SITM 

(tn) 

(tn) 

(tn) 

etc. 

— (TN) 

— (TN) 

~ (TN) 





Note 1: If only the loop number is entered and RETURN is 
depressed, it requests that all equipped TNs on the specified looo 
have ITM set ^ 

Note 2: If only the loop and shelf numbers are entered and 
RETURN is depressed, it requests that all equipped TNs on the 
specified shelf have ITM set 

Note 3: If the loop, shelf and card numbers are entered and 
RETURN is depressed, it requests that all equipped TNs on the 
specified card have ITM set 

Note 4: If the loop, shelf, card and unit numbers are enter ed , it 
requests that the given terminal has ITM set 

Note 5: If ALL is entered, this sets ITM for all equipped TNs in 
the entire system. 
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TIME-OF-DAY 


Time-of-Day 
Adjustment 


Example: 

.SITM 
SHELF 04 1 
LOOP 05 
TN 11 3 4 1 
CARD 19 1 1 

— 07 

— 061 


8.34 Clear Line Traffic TNs. The format for this command. CITM, is 
exactly the same as for command SITM except that the ITM class of 
service is removed from the terminals specified. 

8.35 Query System Time of Day. The command format is: 

TTAD (day) (month) (year) (hour) (minute) (second) 

Example: 

.TTAD WED 24 11 1976 15 41 49 


8.36 Set The Time of Day and the Date. The command format is: 
STAD (DAY) (MONTH) (YEAR) (HOUR) (MINUTE) (SECOND) 
Example: 

.STAD 28 12 1975 11 15 47 


Note 1: Except for the year, the other entries in the time-of-day 
output are 2-digit numbers. The year may be any year from 1901 
to 2099 inclusive. It may be input as a full 4-digit field or as a 
2-digit short form. The 2-digit short form is assumed to be in the 
range 1976 to 2075 and the appropriate addition is made when 
calculating the day-of-week and leap years. 

Note 2: The time-of-day printed is the present time-of-day. not 
the time-of-day that traffic data was last collected into the 
holding registers. 

Note 3: When the date is defined via the STAD command, the 
system calculates the correct day of the week. This is then printed 
with future TTAD commands and is used to check the “days of the 
week” portions of the schedules. 

8.37 The time-of-day can be adjusted from 0 to ±60 s in increments 
of 100 ms. The increment is prefixed with the digit 1 for positive and 0 
for negative increment The commands for time-of-day adjustments 
are: 

8.38 Query The Time-Of-Day Adjustment. 

TDTA (adjustment) 



PRACTICE 553-2001-450 


ACCESSING DATA IN 
HOLDING REGISTERS 


Example: 

.TDTA 0 12 

8.39 Set System TIme-Of-Day Adjustment. 
SDTA (adjustment) ~ (ADJUSTMENT) 
Example: 

.SDTA 0 12 — 1 142 


8.40 Data held in the holding registers can be output immediately 
and/or tested against threshold values. The data is accumulated over the 
previous measurement period. Data in the accumulating registers is not 
accessible. 

8.41 Both the system and the customer traffic measurement data can be 
printed immediately. The data is output from the holding registers and 
is that data which was collected the last time the relevant traffic was 
scheduled. 

8.42 Invoice System Traffic Data. The following command is used to 
invoke the immediate printing of system traffic data: 

INVS (OPTIONS) 

Example: 

.INVS 13 


8.43 Invoke Customer Traffic Data. Use the following command to 
invoke immediate printing of customer traffic data; 

INVC (CUSTOMER) (OPTIONS) 

Example: 

.INVC 0 13 

8.44 Invoke Customer Network Traffic Data. Use the following 
command to invoke immediate printing of customer network traffic 
data: 

INVN (CUSTOMER) (OPTIONS) 

Example: 

.INVN 0 2 


8.45 The threshold tests are for the system and/or customer thresholds. 
When an invoked threshold test passes, OK is output 


8.46 Invoke System Threshold Tests. The command format is: 
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CUSTOMER WITH 

FEATURE 

MEASUREMENTS 


n 


SYSTEM 

IDENTIFICATION 



ITHS (THRESHOLD CODES) 

Example: 

.ITHS 1 2 

8.47 Invoke Customer Threshold Tests. The command format is*. 

ITHC (CUSTOMER) (THRESHOLD CODES) 

Example: 

.ITHC 0 1 3 

8.48 Query Customer Set For Features Measurements. The format 
for this command is: 

TCFT (customer) 

Example: 

.TCFT 2 

8.49 Set Customer To Receive Feature Measurements. The format 
for this command is: 

SCFT (customer) -- (CUSTOMER NUMBER) 

Example: 

.SCFT 2 — 1 

8.50 Each SL-1 system has a unique system ID number selected from 
000 to 999. The 3-digit ID number can be queried or set by the 
following commands. 

8.51 Query System Identification. The command format is: 

TSID (system identification number) 

Example: 

.TSID 213 

8.52 Set System Identification. The command format is: 

SSID (system id number) — (SYSTEM ID NUMBER) 

Example: 

.SSID 213 — 216 
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IDLE TITLES 


ARS QUEUING 


8.53 The IDLT command is used to suppress the printing of the title 
(i.e., TFSOOO) and the date and time in cases where traffic measurement 
is scheduled but no other data is printed. There are two options: 

0 - No title will be printed unless further data is also to be printed. 

1 ” The title will be printed whenever traffic measurement is scheduled 
even when no other data is to be automatically printed. 

8.54 The default option is 1, i.e., the title is normally printed. The 
format of the command is: 

IDLT (option) 

Example: 

.IDLT 0 

8.55 Query ARSQ Code Options. The command format is: 

TACC (CUSTOMER) (options) 

Example: 

.TACC 2 0 2 3 

8.56 Set ARSQ Code Options. The command format is: 

SACC (CUSTOMER) (options) — (OPTIONS)* 

Example: 

.SACC 2 0 2 3 — 1 


Clear ARSQ Code Options. The command format is: 

CACC (CUSTOMER) (options) — (OPTIONS)* 

Example: 

.CACC 2 0 2 3 — 2 3 

8.58 Accessing data in ARSQ code holding registers. The 
command format is: 

lACC (CUSTOMER) — (OPTIONS)* 

Example: 

.lACC 2 — 0123 
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ARS ROUTINGS 


8.59 The Set/ Clear/Invoice commands for Routings differ from other 
TFC commands in that the system will accept, at most, 12 entnw ^r 
line. As the number of Routings for a customer can reach 255, me 
system will automatically go to a new line and prompt the u«r i^or 
further options. Depressing the carriage return terminates further 

prompting. 

8.60 Query Routing Options. The command format is: 

TSBC (CUSTOMER) (options) 


Example: 

.TSBC 3 1 2 7 10 11 


8.61 Set Routing Options. The command format is: 

SSBC (CUSTOMER) (options) — (OPTIONS)* 

Example: 

.SSBC 3 1 2 7 10 11 4 5 

8.62 Clear Routing Options. The command format is: 

CSBC (CUSTOMER) (options) ~ (OPTIONS)* 

Example: 

.CSBC 3 1 2 7 10 11 — 1 7 11 

8.63 Accessing data in Routing holding registers. The command 
format is: 

ISBC (CUSTOMER) ~ (OPTIONS)* 

Example: 

.ISBC 3 — 1 2 3 4 5 6 7 8 9 10 11 12 

— 20 21 22 23 24 25 26 27 28 29 30 31 32 

— 41 42 
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Table 8-C 

TRAFFIC MEASUREMENT ERROR MESSAGES 


ERROR INTERPRETATION 

MESSAGE 


TFC200 

TFC201 

TFC202 

TFC203 

TFC204 

TFC205 

TFC206 

TFC207 

TFC208 

TFC209 

TFC209 

TFC210 

TFC210 

TFC211 

TFC211 

TFC212 

TFC213 

TFC213 

TFC214 


Syntax. Illegal character has been input 

The parameter specified is out of range. 

The loop specified is not equipped. 

The card specified is not equipped. 

The unit specified is not equipped. 

Program bug - should never happen. 

Customer specified is not equipped. 

Traffic Print program is busy with scheduled 
output 

Traffic Control program cannot be invoked 
from an SL-1 maintenance set 

ARST package unavailable. 

The Network Traffic (NTRF) feature is not 
equipped (Generic XI1). 

ARS unequipped for customer. 

There is no ESN customer data block (Generic 

Xll). 

Traffic block does not exist 

There is no ESN Data for the requested item 
(Generic Xll). 

The NCOS data block does not exist in the 
system (Generic Xll). 

IMS package not equipped. 

Password does not have access to this 
customer data (Generic X08). 

Password does not have access to system 
commands (Generic X08). 

Routing control has been invoked from an 
attendant console; the time (hh mm ss) and 
termination number (TN) of the console are 
included in the message. 


TFN401 
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Table 8-C Continued 

TRAFFIC MEASUREMENT ERROR MESSAGES 



ERROR 

MESSAGE 

INTERPRETATION 


TFN402 

Routing control has been deactivated from an 
attendant console; the time and TN of the 



console are included in the message. 




